Skip to content

ci(release): dispatch recompile-safe-output-fixtures after asset upload#911

Merged
jamesadevine merged 1 commit into
mainfrom
jamesadevine/trigger-recompile-on-release
Jun 8, 2026
Merged

ci(release): dispatch recompile-safe-output-fixtures after asset upload#911
jamesadevine merged 1 commit into
mainfrom
jamesadevine/trigger-recompile-on-release

Conversation

@jamesadevine

Copy link
Copy Markdown
Collaborator

Problem

The recompile-safe-output-fixtures workflow is supposed to fire on release: published, but no release-triggered run has ever happened — v0.32.0 and v0.33.0 both went unhandled:

$ gh run list --event=release --workflow=recompile-safe-output-fixtures.lock.yml
(empty)

Root cause: release.yml uses release-please-action with the default GITHUB_TOKEN. GitHub Actions actively suppresses workflow triggers from events created by GITHUB_TOKEN to prevent recursive runs (docs), so the release: published event is never delivered.

Fix

Add a final trigger-recompile-safe-output-fixtures job at the end of release.yml that explicitly dispatches recompile-safe-output-fixtures.lock.yml via gh workflow run, using GH_AW_CI_TRIGGER_TOKEN (a PAT) so the dispatched run can itself open a PR.

  • Ordering: needs: [release-please, checksums] — runs only after every binary and checksums.txt have been uploaded. This makes the recompile workflow's Step 2 bounded retry effectively a no-op.
  • Tag pinning: passes -f version=$TAG so the recompile resolves to the just-released version rather than re-querying "latest" (avoids races against a hypothetical newer release that lands mid-run).
  • Both code paths: handles both push-triggered release-please publishes and manual workflow_dispatch of release.yml, mirroring the existing if: pattern on the other build jobs.

Backfill

Once this merges, run the following to backfill v0.32.0 and v0.33.0:

gh workflow run recompile-safe-output-fixtures.lock.yml --repo githubnext/ado-aw --ref main -f version=v0.33.0

Why not alternatives

  • Switch release-please to use a PAT (smaller diff): would work, but would attribute every release to a bot identity, and would still rely on release: published reliably propagating ordering after asset uploads. The explicit dispatch approach removes the asset-upload race entirely.
  • workflow_run on Release completion: less clean — runs on the default branch and would still need to re-resolve the tag.

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>
@jamesadevine jamesadevine merged commit 3443962 into main Jun 8, 2026
13 checks passed
@jamesadevine jamesadevine deleted the jamesadevine/trigger-recompile-on-release branch June 8, 2026 19:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant