A release is never held because main moved: the build accepts a green check of a descendant of the tagged commit #3968

A release is no longer held when main moves on: if a later main commit that contains the tagged commit has a green check, the release build accepts that check.

What changed

• The route that answers a release. GET /api/v1/repos/:owner/:name/commits/:oid/check still gives the tagged commit's own ok, failed or pending unchanged. When that check is superseded (main moved on and cancelled it) or none (the commit was never checked on its own, e.g. it landed inside a batch), the new releaseCheck in src/checks/commit_check.ts looks at main's checks of later commits, newest first:

- it skips any commit that does not contain the tag (git merge-base --is-ancestor, through isAncestor); - the first green one answers ok; - if none is green but one is still running, the answer is pending, so the release waits for it instead of stopping at once.

• What it ignores. A red later check says nothing about the tag and is passed over. Only checks newer than the tag's own are read, and at most 50 distinct commits are asked.
• New checkedCommit field. The response names whose check answered: the tagged commit itself or the later one. commitCheck stays a plain database read; checkOfCommit in src/actions/runs.ts is now async and passes in the git ancestry check.
• release.yml: the success line now prints checkedCommit, and the superseded message says no green or running later check contains the tag. The polling logic is unchanged. docs/ops/ROLL.md and README.md describe the fallback.

Choices

• I did not take the issue's other option (main never cancels a check of a tagged commit). It would make every release wait on a check that main no longer needs.
• If the latest later check is red and nothing is running, the answer stays superseded and the release stops. A red main holding a release is the intended behaviour.

Tests

• test/commit-check.test.ts has new unit tests for releaseCheck. They cover:

- the tag's own verdict still deciding; - two landings cancelling the tag's check, after which the descendant's green check answers; - a commit checked only as part of a batch; - a later commit that doesn't contain the tag, and a red one, not answering for it; - a green check older than the tag's own being ignored.

• An end-to-end HTTP test with real git does what the issue asks: it tags a commit, lands two commits that cancel its check, and gets pending and then ok from the descendant. A green check on another branch does not count.
• One existing test changed: "a commit main never checked is none" compares the whole response exactly, so it now expects the added checkedCommit field. The test was out of date, not the code.
• bun test test/commit-check.test.ts test/release-gate.test.ts passes (18 tests) and tsc --noEmit is clean.

To try it, wait until main has landed after a tag (or reproduce 0.7.216's case) and read …/commits/<tag sha>/check. It answers ok with checkedCommit set to the later green commit.

🤖 Generated with Claude Code

Closes #3966

A release is no longer held when main moves on: if a later main commit that contains the tagged commit has a green check, the release build accepts that check.

What changed

• The route that answers a release. GET /api/v1/repos/:owner/:name/commits/:oid/check still gives the tagged commit's own ok, failed or pending unchanged. When that check is superseded (main moved on and cancelled it) or none (the commit was never checked on its own, e.g. it landed inside a batch), the new releaseCheck in src/checks/commit_check.ts looks at main's checks of later commits, newest first:

- it skips any commit that does not contain the tag (git merge-base --is-ancestor, through isAncestor); - the first green one answers ok; - if none is green but one is still running, the answer is pending, so the release waits for it instead of stopping at once.

• What it ignores. A red later check says nothing about the tag and is passed over. Only checks newer than the tag's own are read, and at most 50 distinct commits are asked.
• New checkedCommit field. The response names whose check answered: the tagged commit itself or the later one. commitCheck stays a plain database read; checkOfCommit in src/actions/runs.ts is now async and passes in the git ancestry check.
• release.yml: the success line now prints checkedCommit, and the superseded message says no green or running later check contains the tag. The polling logic is unchanged. docs/ops/ROLL.md and README.md describe the fallback.

Choices

• I did not take the issue's other option (main never cancels a check of a tagged commit). It would make every release wait on a check that main no longer needs.
• If the latest later check is red and nothing is running, the answer stays superseded and the release stops. A red main holding a release is the intended behaviour.

Tests

• test/commit-check.test.ts has new unit tests for releaseCheck. They cover:

- the tag's own verdict still deciding; - two landings cancelling the tag's check, after which the descendant's green check answers; - a commit checked only as part of a batch; - a later commit that doesn't contain the tag, and a red one, not answering for it; - a green check older than the tag's own being ignored.

• An end-to-end HTTP test with real git does what the issue asks: it tags a commit, lands two commits that cancel its check, and gets pending and then ok from the descendant. A green check on another branch does not count.
• One existing test changed: "a commit main never checked is none" compares the whole response exactly, so it now expects the added checkedCommit field. The test was out of date, not the code.
• bun test test/commit-check.test.ts test/release-gate.test.ts passes (18 tests) and tsc --noEmit is clean.

To try it, wait until main has landed after a tag (or reproduce 0.7.216's case) and read …/commits/<tag sha>/check. It answers ok with checkedCommit set to the later green commit.

🤖 Generated with Claude Code

Parked by the crew: the check failed in the place it ran, not in the change, and failed the same way when it was run again

When main moves on before a tag's own check runs, the release still lands: GET …/commits/:oid/check now accepts a green check of a later main commit that contains the tagged commit. This push makes the two changes review asked for.

1. The release workflow is reverted. .forgejo/workflows/release.yml is back to exactly what it is on main, and the pull no longer touches it. The gate still builds only on ok, and all of the new behaviour is in the endpoint. Readers of a run can see which commit was checked from checkedCommit in the JSON, and README and ROLL.md explain it. If the release log line should name that commit, that belongs in a separate issue for a person to take.

2. The git work on this unauthenticated GET is bounded.

• releaseCheck now takes history: { has, contains } instead of a bare contains callback.
• has() is asked once, just before the first contains. If the commit is not in the repository, the commit's own answer (none) comes back without starting any git merge-base.
• In checkOfCommit (src/actions/runs.ts), has() calls the new hasCommit in src/git/local.ts. It runs one git cat-file -e <oid>^{commit} after the same isSafeRef check that isAncestor uses.
• DESCENDANTS drops from 50 to 10, so a commit that does exist costs at most 10 ancestry checks per request.

Tests in test/commit-check.test.ts:

• An unknown commit answers none, has is called once, and contains is never called.
• With more than DESCENDANTS later green commits, contains is called exactly DESCENDANTS times.
• The existing releaseCheck tests now pass { has: true, contains }. That is a signature change to tests this pull added; none of their assertions changed.

bun test test/commit-check.test.ts passes, 17 tests including the real-git HTTP test. The type check did not run: in this sandbox both bun install and bun x tsc stop with "unable to write files to tempdir: ReadOnlyFileSystem". That may be the same environment failure behind the earlier parked check. The forge's check will run the type check on this push.

To try it: curl $PREVIEW/api/v1/repos/<owner>/<repo>/commits/<40-hex not in the repo>/check answers none without starting any merge-base. For a tagged commit whose own check was superseded, it answers ok with checkedCommit naming the later green main commit.

🤖 Generated with Claude Code