release-please PR orphaned by manual v0.3.0 tag #37
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
The release-please PR at branch
release-please--branches--main--components--agentic-os(commitcbd11df, "chore(main): release 0.3.0") is now orphaned. I taggedv0.3.0manually at main HEAD because the release-please PR was stale (last touched 2026-05-20, didn't include the 2026-05-26 gitignore-respect + cleanup commits) and the rollout was blocking on a published tag.The PR now proposes a version that already exists as a real tag.
Cleanup
.github/workflows/in the local checkout, so the trigger is likely org-level - find and inspect.v0.3.1(or similar) as the next bump, notv0.3.0again.Related context
880c740(the SKIP_DIR_NAMES prune commit), which is parent of9b30420(DEFAULT_REV bump). The tag sits between two commits because the prune was the natural "release" point and DEFAULT_REV is a chore.version = "0.2.5"(release-please was managing it; my manual tag didn't touch it). On the next real release-please run, this should bump to the actual current tag.Why not let release-please auto-resolve
It might auto-resolve fine on next run, but if the workflow trigger is broken (PR has been stale 6 days), manual investigation is needed to find why. Filing this as a tracker either way.