jdaugherty commented on PR #16213: URL: https://github.com/apache/grails-core/pull/16213#issuecomment-5925737238
Summary of where this landed after going through the history and the live state. **What this PR now does.** The head (02a2338) removes the `pull_request` trigger. The title and body still describe the first commit's per-PR concurrency group, which the second commit reverted, so they need updating. Removing the trigger is right: - The trigger existed for the autolabeler, and the action pinned here can no longer label. release-drafter 7 (picked up here on March 16) split labelling into a separate `release-drafter/release-drafter/autolabeler` action; the root action runs only the drafter and no longer has the `disable-releaser` / `disable-autolabeler` inputs. Every `fix/`, `test/`, `docs/` and `deps/` branch merged this week has no label. - A PR run writes the same draft the last push already wrote (notes are built from merged PRs), and on a fork PR it cannot write at all: "Resource not accessible by integration", hidden by `continue-on-error`. - Yesterday there were eight PR-event writes to the 8.0.x draft in fifteen hours while the RC2 pipeline was gated. That volume is what makes a collision with a release likely, and it is what cancelled unrelated PRs' checks. **The concern I raised: the drafter vs. a release in progress.** The shared concurrency group from January (c7e169ad6e) was removed in May (d4608a4b65) because the pipeline waits at approval gates for days and every push queued a drafter run behind it. So the drafter has been running during releases since May; this PR neither adds nor removes that. The actual hazard is narrower than "any overlap": - The drafter only writes to a release whose `draft` flag is true. It takes the first draft targeting the branch, regardless of tag, and PATCHes its `tag_name`, `name`, `body`, `target_commitish` and `draft: true`. - `pre-release` force-moves the tag, which flips the release back to a draft until the script PATCHes `draft: false`. A drafter run in that window adopts the release and rewrites it. The same happens to a drafter run already in flight when the draft is published. - A published release is never touched. The RC2 pipeline has been gated since Sept 29; every drafter run since logs "last release: v8.0.0-RC2" and updates the separate v8.0.0 draft. RC2 is untouched. **What we decided.** 1. Keep the removal of the `pull_request` trigger. 2. Add a hold-off step as the first step of the drafter job. It lists `release.yml` and `release-close.yml` runs, maps a release run's head ref (the tag, e.g. `v8.0.0-RC2`) to its branch (`8.0.x`), and if any run for the branch is not `completed`, including one waiting at a vote gate, the seed and drafter steps are skipped and the draft is left exactly as it was. It skips rather than queues, so the May problem does not come back. The next version is not known until the close merges back anyway, so a stale draft during a release costs nothing; the first push after the pipeline completes brings it up to date. If the runs cannot be listed it holds off and warns. The job gains `actions: read` for the listing. A commit adding this follows on this branch (maintainer edits are enabled). The merge with current 8.0.x, which has since bumped the pin to v7.7.0, is clean, and `validateRepositoryConventions` passes on the result. 3. A bad release is deleted and restaged, never flipped back to draft, so the guard keys on pipeline runs rather than on release objects. When restaging, cancel the stale pipeline run, or it keeps the drafter held. **Not covered, and not coverable by any group or guard:** a drafter run that is already inside the action (the few seconds between listing releases and writing) when Publish is clicked will rewrite a hand-edited RC tag. Publish after the last merge's drafter run has finished. **Separate follow-ups, not for this PR:** restoring labels needs `release-drafter/release-drafter/autolabeler@<sha>` on the ASF allowlist (`approved_patterns.yml` carries only `release-drafter/release-drafter@*`), then its own small `pull_request` workflow with `pull-requests: write`; labelling fork PRs would additionally need `pull_request_target`. Every drafter run also warns that `categories[*].labels` is deprecated in favour of `when:`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
