Nectenda/nectenda

Watch

Fork 0

Queue release-note runs instead of cancelling them, and check the named head #128

Merged

cruelacid merged 1 commit from worktree-release-note-race into main

2026-09-23 18:23:25 +01:00

cruelacid commented

2026-09-23 18:17:11 +01:00

Owner

This follows PR #127, which had a green release-note run and still could not merge.

Cause: pushing a commit and editing the PR description within one second started two release-note runs, one for synchronize and one for edited. Forgejo's automatic concurrency cancelled the older run. A cancelled job reports its commit status as failure. Both runs reported on the same commit under the same context, so they alternated 35 statuses over 15 s, and the cancelled one's failure was posted last. Branch protection read that failure.

Fix:

An explicit concurrency: { group: release-note-<PR>, cancel-in-progress: false }. A second run now queues instead of cancelling, both finish in event order, and the newest result posts last.
actions/checkout at github.event.pull_request.head.sha. An edited event that arrives before Forgejo has processed a just-made push is recorded against the previous head, so its default checkout judged the old tree while its status landed on the new commit.

edited stays, so fixing a description still re-checks without re-running CI.

Verification, on this PR (race reproduced by this very edit): the race is reproduced deliberately (force-push and description edit in the same second). The expected result is two runs, the second waiting rather than cancelling, both successful, and no failure status on the head.

Changelog

NONE

🤖 Generated with Claude Code

https://claude.ai/code/session_01StURdiv33xnMfE2XRyg8Lt

This follows PR #127, which had a green release-note run and still could not merge. **Cause:** pushing a commit and editing the PR description within one second started two `release-note` runs, one for `synchronize` and one for `edited`. Forgejo's automatic concurrency cancelled the older run. **A cancelled job reports its commit status as `failure`.** Both runs reported on the same commit under the same context, so they alternated 35 statuses over 15 s, and the cancelled one's `failure` was posted last. Branch protection read that failure. **Fix:** - An explicit `concurrency: { group: release-note-<PR>, cancel-in-progress: false }`. A second run now **queues** instead of cancelling, both finish in event order, and the newest result posts last. - `actions/checkout` at `github.event.pull_request.head.sha`. An `edited` event that arrives before Forgejo has processed a just-made push is recorded against the previous head, so its default checkout judged the old tree while its status landed on the new commit. `edited` stays, so fixing a description still re-checks without re-running CI. **Verification, on this PR** (race reproduced by this very edit): the race is reproduced deliberately (force-push and description edit in the same second). The expected result is two runs, the second waiting rather than cancelling, both successful, and no `failure` status on the head. ## Changelog NONE 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01StURdiv33xnMfE2XRyg8Lt

cruelacid added the

area:ops

label

2026-09-23 18:17:11 +01:00

cruelacid added 1 commit

2026-09-23 18:17:11 +01:00

Queue release-note runs instead of cancelling them, and check the named head

Release note / release-note (pull_request) Successful in 15s

Details

CI / promote (pull_request) Has been cancelled

Details

CI / e2e (pull_request) Has been cancelled

Details

CI / build (pull_request) Has been cancelled

Details

1a00314fa1

Pushing a commit and editing a pull request's description within a second
starts two release-note runs. Forgejo's automatic concurrency cancelled the
older, a cancelled job reports its status as failure, and the two runs —
same commit, same context — alternated until the cancelled one posted last.
PR #127 had a green run and still could not merge.

An explicit group with cancel-in-progress: false queues the second run
instead: nothing is cancelled, both finish in event order, and the newest
result is the one posted last.

The `edited` run was also recorded against the previous head, because the
push had not been processed yet, so its default checkout judged the old
tree while its status landed on the new one. It now checks out
github.event.pull_request.head.sha, the commit the status is for.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01StURdiv33xnMfE2XRyg8Lt

cruelacid force-pushed worktree-release-note-race from 1a00314fa1

Release note / release-note (pull_request) Successful in 15s

Details

CI / promote (pull_request) Has been cancelled

Details

CI / e2e (pull_request) Has been cancelled

Details

CI / build (pull_request) Has been cancelled

Details

to 956701a9a1

Release note / release-note (pull_request) Successful in 11s

Details

CI / e2e (pull_request) Successful in 5m10s

Details

CI / build (pull_request) Successful in 5m11s

Details

CI / promote (pull_request) Has been skipped

Details

CI / build (push) Successful in 4m38s

Details

CI / e2e (push) Successful in 4m50s

Details

CI / promote (push) Successful in 30s

Details

2026-09-23 18:17:29 +01:00

Compare

cruelacid merged commit 956701a9a1 into main

2026-09-23 18:23:25 +01:00

No reviewers

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Nectenda/nectenda!128

No description provided.

Rows
Columns