GeezerVison

Follow-up to #3631, addressing review findings. v5.6.2 already released cleanly through #3631. The tag points at the Release v5.6.2 commit with a non-SNAPSHOT pom, so none of this is a live breakage.

The common thread: every check that can reject a release now runs in publish, before the deploy. Maven Central artifacts are immutable once published, so a check that fails after the deploy leaves a release that can't be retried.

Keep the concurrency group, with an accurate rationale. An earlier commit on this branch removed it, because the default queue keeps only one pending run: with a release running and a second pending, a third cancels the second. That was reverted (9a246ed). Without the group, two releases from the same branch can both deploy, and then one loses the atomic branch push with immutable artifacts and no release commit. A cancelled pending run is the better worst case: it has deployed nothing and can simply be re-run. The comment in release.yml now says this.

Check the tag ancestry in publish, not finalize-release. The check is equivalent against the branch tip, since the release commit is always a child of it, and running it before the deploy means a release cut from an unrelated commit fails while it's still retryable. The tag's existence and its peeling to a commit are tested separately, so a tag that resolves to something other than a commit fails loudly instead of looking like an absent tag and skipping the check.

Lease the tag update. The ancestry check reads the tag as fetched at checkout, but +refs/tags/... would then overwrite whatever the remote holds at push time. The push now leases against the OID observed during the check (the tag ref itself, not the commit it peels to), with an empty expectation when the tag didn't exist. A tag moved by anyone else in between fails the push, and --atomic means the branch doesn't move either.

Guard against a release moving the branch backwards. The next development version is derived from the released version, so releasing a tag older than the branch's own version would set the branch to versions already released. The guard runs in publish, comparing the released version against the branch's development version before the deploy. finalize-release repeats it as a postcondition on the derived next version. This is deliberately not CodeRabbit's suggested fix of restoring the checked-out version: that breaks the common case, since releasing v5.7.0 from main on 5.6.2-SNAPSHOT must land on 5.7.1-SNAPSHOT, not go back to 5.6.2-SNAPSHOT. A monotonicity guard covers both.

Keep the pom version parser inline in the workflow. Both jobs read a pom version, so the parser is a single POM_VERSION_PY in the workflow-level env, run with python3 -c (1c19f3e). It deliberately isn't a script in the repo: the jobs check out the release branch, and maintenance branches (5.0.x, 5.2.x, 5.3.x) wouldn't have it.

Document the manual recovery from a rejected push. The concurrency group keeps releases apart, but not a merge landing on the branch while publish runs. That rejects the final push after the deploy, and nothing in the workflow can get past it: re-running the workflow fails in publish on the immutable artifacts, and re-running finalize-release rebuilds on the same stale commit. Both refs are left safe (branch on a SNAPSHOT version, tag where GitHub created it), so a comment on the push step (c91fb9c) now describes finishing the release by hand: tag a release commit built on the deployed commit, then bump the current branch tip to the next SNAPSHOT.

Not changed

Copilot also flagged that the push uses GITHUB_TOKEN, so snapshot-releases.yml won't run for the release commits. That's accurate (it last ran on 832857dfa and not on 0d612f32a/70988d132), but it isn't a regression, since the previous ad-m/github-push-action used the same token, and it's arguably desirable. It also doesn't affect #3631's rationale, where the trigger was always a subsequent human merge onto a branch left at a release version.

Making the workflow itself survive a concurrent merge (building the SNAPSHOT bump on the current branch tip instead of on the release commit) would remove the need for the manual recovery, but it is a larger change to the workflow and is left for a follow-up.

Testing

Run-blocks extracted from the YAML and executed verbatim against scratch repos with a stubbed mvnw and real git 2.55.0, on the current head.

Tag check in publish:

• Tag absent, or a lightweight or annotated tag on an ancestor → passes.
• Tag on an unrelated commit → fails, before any deploy.
• Lightweight or annotated tag pointing at a tree → fails with "does not resolve to a commit".

Version checks in publish:

• Branch on 5.6.3-SNAPSHOT: v5.6.3, v5.6.4, v5.7.0, v5.10.0, v6.0.0 pass; v5.6.2, v5.0.0, v4.9.9 fail.
• Branch on 5.10.0-SNAPSHOT: v5.9.9 fails, v5.10.0 passes, so versions compare numerically rather than as text.
• v5.6.3-rc1 and v5.6 are rejected as not plain major.minor.patch.
• A pom without the Maven namespace makes the parser fail loudly. POM_VERSION_PY returns 5.6.3-SNAPSHOT for both the root pom and operator-framework-core/pom.xml, which inherits its version from the parent.

Push step:

• Matching lease on an existing tag → tag moved. Empty lease with the tag absent → tag created.
• Empty lease with the tag present → rejected.
• Tag moved by another actor after it was read → rejected on the stale lease, remote branch and tag both untouched.
• Concurrent merge onto the branch → push rejected, tag unmoved.

The end-to-end runs from the earlier revision (v5.7.0 from 5.7.0-SNAPSHOT → tagged 5.7.0, branch 5.7.1-SNAPSHOT; likewise v5.8.0 and v6.0.0 from 5.7.3-SNAPSHOT) haven't been repeated. The later commits changed only the checks above, the parser's location, and comments.

Summary by CodeRabbit

• Bug Fixes

  • Added checks to prevent publishing releases based on commits outside the target branch’s history.
  • Added version checks to prevent release preparation or finalization from moving the branch back to an older version.
  • Improved tag updates to avoid overwriting changes made by another release process.

• Release Process

  • Improved version detection and validation before publishing artifacts.