jamesfredley commented on PR #15623:
URL: https://github.com/apache/grails-core/pull/15623#issuecomment-4521006536
@jdaugherty Pulled the workflow files and run history to verify. The
specific mechanism you described - tag creation triggering the drafter -
doesn't match what's in the code or the run logs, but the broader overlap
concern is real, just through a different path. Receipts below.
### 1. The drafter trigger never matched tags
The pre-PR `release-notes.yml` on `7.0.x` had:
```yaml
on:
push:
branches:
- '[0-9]+.[0-9]+.x'
```
GitHub Actions' `push` event with a `branches:` filter does not fire on tag
pushes - tag pushes require an explicit `tags:` clause, and there isn't one.
Pushing `refs/tags/v7.0.*` alone could not trigger the drafter.
### 2. The pre-release action pushes only a tag ref, never a branch commit
`apache/grails-github-actions/pre-release@asf` (the script invoked from
`release.yml`) does:
```bash
git checkout "v${VERSION}" # detached HEAD at the tag
...
git commit -m "[skip ci] Release v${VERSION}" # commit lives on detached
HEAD
git tag -fa v${VERSION} ...
git push origin "v${VERSION}" --force # ONLY the tag ref is pushed
```
The commit never lands on `7.0.x`. Only the tag is force-pushed, and `[skip
ci]` in the message would suppress workflows on a branch push anyway.
### 3. The three runs cited in the PR description prove it
| Run | Event | Trigger |
|---|---|---|
| 25214035979 (1,400 min) | `push` to `7.0.x` | Merge of PR #15616
(`wrapper-cli-verification`) |
| 25197284620 (2,091 min) | `pull_request` | `fix 4x exception logging` |
| 25167124818 (1,358 min) | `pull_request` | `Where Query documentation
improvements` |
Zero of these are tag-creation events. All three are normal branch / PR
activity that happened to land during a release window.
### Where the overlap concern is right
Drafter and `release.yml` did overlap, just not through tags. The actual
path:
1. Normal PRs keep merging to `7.0.x` during the 72-hour+ ASF vote.
2. Each merge fires the drafter on `push: branches:`.
3. Meanwhile `release.yml` is parked in `waiting` state on its `environment:
release / docs / sdkman` manual-approval gates.
4. Both workflows shared `release-pipeline-${branch}`, so the drafter queued
behind the waiting release run for days until GitHub's 24-hour run cap killed
it.
bito's framing - "they target different releases, so the concurrency group
does not need to be shared" - is correct as the rationale for splitting the
groups. The bug was not that drafter and `release.yml` touched the same release
object (they never did); it was that the shared concurrency group held the
drafter hostage to the manual-approval wait window.
--
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]
