fix(ci): trigger release verification on the Release run, not the release event - #763
Merged
Conversation
…ease event The gate added in #761 never fired. Releases are created by the Release workflow using GITHUB_TOKEN, and GitHub does not raise events from that token — so `release: published` cannot trigger anything for an automated release. The first tag after it landed, v0.28.1, produced no verification run at all. It now keys off the Release workflow completing, which is not subject to that rule, and skips a run that failed or was not started from a tag. v0.28.1 was verified by manual dispatch in the meantime; the next release exercises this path on its own. Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Automated approval for maintainer PR
All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #763 +/- ##
=======================================
Coverage 87.70% 87.70%
=======================================
Files 90 90
Lines 12057 12057
=======================================
Hits 10575 10575
Misses 1193 1193
Partials 289 289
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The gate added in #761 never fired.
Releases here are created by the Release workflow through
softprops/action-gh-releaseusingGITHUB_TOKEN, and GitHub does not raise events from that token — a deliberate guard against recursive workflow runs. Soon: release: [published]is inert for every release this project produces. I wired it that way and merged it without exercising it; the first tag afterwards, v0.28.1, produced no verification run.The repository does have 47 historical
event=releaseruns, which is what made it look plausible — they are all from March, from an era when releases were created by hand.Now it keys off the Release workflow completing, which
workflow_runobserves regardless of which token created what. Two guards come with it: a Release run that did not succeed has nothing to verify, andhead_branchis only a tag when the run came from a tag push, so a Release started another way is skipped rather than verified against a branch name.workflow_dispatchis unchanged.v0.28.1 was verified by manual dispatch in the meantime, so the release itself is not unchecked — but the automation was, which is the same failure mode this gate exists to catch.