ci(release): dispatch recompile-safe-output-fixtures after asset upload#911
Merged
Merged
Conversation
Releases published via release-please use the default GITHUB_TOKEN, which GitHub Actions actively suppresses from triggering other workflows to avoid recursive runs. As a result, the recompile-safe-output-fixtures workflow's release: published trigger has never fired (v0.32.0 and v0.33.0 both went unhandled). Add a final job at the end of release.yml that explicitly dispatches the recompile workflow once binaries and checksums are uploaded, using GH_AW_CI_TRIGGER_TOKEN so the dispatched run can itself open a PR. The tag is passed explicitly to avoid races against a hypothetical newer release landing mid-run. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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.
Problem
The
recompile-safe-output-fixturesworkflow is supposed to fire onrelease: published, but norelease-triggered run has ever happened — v0.32.0 and v0.33.0 both went unhandled:Root cause:
release.ymlusesrelease-please-actionwith the defaultGITHUB_TOKEN. GitHub Actions actively suppresses workflow triggers from events created byGITHUB_TOKENto prevent recursive runs (docs), so therelease: publishedevent is never delivered.Fix
Add a final
trigger-recompile-safe-output-fixturesjob at the end ofrelease.ymlthat explicitly dispatchesrecompile-safe-output-fixtures.lock.ymlviagh workflow run, usingGH_AW_CI_TRIGGER_TOKEN(a PAT) so the dispatched run can itself open a PR.needs: [release-please, checksums]— runs only after every binary andchecksums.txthave been uploaded. This makes the recompile workflow's Step 2 bounded retry effectively a no-op.-f version=$TAGso the recompile resolves to the just-released version rather than re-querying "latest" (avoids races against a hypothetical newer release that lands mid-run).push-triggered release-please publishes and manualworkflow_dispatchofrelease.yml, mirroring the existingif:pattern on the other build jobs.Backfill
Once this merges, run the following to backfill v0.32.0 and v0.33.0:
Why not alternatives
release: publishedreliably propagating ordering after asset uploads. The explicit dispatch approach removes the asset-upload race entirely.workflow_runonReleasecompletion: less clean — runs on the default branch and would still need to re-resolve the tag.