ci(release-npm): switch to workflow_run trigger so npm publish auto-fires#261
Merged
ci(release-npm): switch to workflow_run trigger so npm publish auto-fires#261
Conversation
…ires after Release
The Release workflow creates the GitHub Release page using the default
GITHUB_TOKEN, and GitHub deliberately suppresses downstream workflow
triggers from runs that authenticated with GITHUB_TOKEN (loop-prevention
guarantee). As a result, release-npm.yml's `release: published` trigger
never fires for v0.7.0 or v0.8.0 — both stuck without npm publication
despite the binary archives being on the GitHub Release page.
Switch to workflow_run on the upstream Release workflow. This is the
documented escape hatch for chaining workflows when the upstream uses
GITHUB_TOKEN. Side effects:
* head_branch on a tag-push source workflow is the tag name itself
(e.g. v0.8.0), so version resolution stays straightforward.
* Guard added against non-release tags so a manual Release run on a
branch ref doesn't accidentally trigger an npm publish.
* Both jobs gated on workflow_run.conclusion == 'success' so failed
upstream releases don't fire downstream publishes; workflow_dispatch
bypasses the gate for manual backfills.
Backfilling v0.7.0 and v0.8.0 npm publication will be done via
workflow_dispatch once this lands on main.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark 'Rivet Criterion Benchmarks'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.
| Benchmark suite | Current: a3218bf | Previous: 9b45c86 | Ratio |
|---|---|---|---|
link_graph_build/10000 |
38478901 ns/iter (± 3117364) |
29210248 ns/iter (± 1823498) |
1.32 |
query/10000 |
148433 ns/iter (± 1277) |
110920 ns/iter (± 1377) |
1.34 |
This comment was automatically generated by workflow using github-action-benchmark.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
1 participant
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.
Summary
release-npm.ymlhasn't fired since v0.6.0 and fixes it.GITHUB_TOKEN. GitHub deliberately suppresses downstream workflow triggers from runs that authenticated withGITHUB_TOKEN(loop-prevention guarantee), so the historicalrelease: publishedtrigger on this file never fires for v0.7.0 / v0.8.0 — both stuck without npm publication despite binaries being on the Release page.workflow_runon the upstream Release workflow — the documented escape hatch for chaining workflows when the upstream usesGITHUB_TOKEN.Why this approach
workflow_run(this PR)release.yml'sgh release createRELEASE_PATsecretrelease.ymlPicked A.
Notable changes
head_branchon a tag-pushed source workflow is the tag name itself (e.g.v0.8.0), so version resolution stays one liner.TAGmatches^v[0-9]+\.[0-9]+\.[0-9]+.workflow_run.conclusion == 'success'so failed/cancelled Release runs don't fire downstream publishes;workflow_dispatchbypasses the gate for manual backfills.concurrency:block consistent with chore(ci): add concurrency control to all workflows #258.Backfill plan
Once this lands on
main, manually dispatch the npm publish for the two stuck releases:Both have all 5 platform binary archives present on their Release pages, so the platform-package jobs will succeed and the root
@pulseengine/rivetpackage will publish.Conflict note
#258(CI concurrency hardening) also touchesrelease-npm.yml's top section. If #258 lands first, this PR will need a small rebase to keep the new variable names (workflow_run.head_branchinstead ofrelease.tag_name). Either order works.Test plan
gh workflow run release-npm.yml -f version=v0.7.0→ all 5 platform packages publish, then root publishes.gh workflow run release-npm.yml -f version=v0.8.0→ same.npm view @pulseengine/rivet versionreturns0.8.0.release-npm.ymlviaworkflow_run(validates the actual fix).🤖 Generated with Claude Code