ci(release-npm): switch to workflow_run trigger so npm publish auto-fires#261
Merged
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! |
avrabe
added a commit
that referenced
this pull request
May 10, 2026
#261 already added a concurrency block to release-npm.yml when switching the trigger to workflow_run. Rebasing this branch on top stacked the original release: published variant on top, producing duplicate top-level concurrency keys (invalid YAML). Drop the now-redundant block; #261's block (keyed on github.event.workflow_run.head_branch) is the correct one for the current trigger. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
avrabe
added a commit
that referenced
this pull request
May 10, 2026
* chore(ci): add concurrency control to all workflows
Add top-level `concurrency:` blocks to every workflow so superseded PR
runs are cancelled while runs on `main`, tags, releases, and scheduled
events complete normally. Org-wide context: 93 workflows queued across
the org as of 2026-05-02 with the oldest job 23h old; rivet has been
intermittently sitting at 5h+ runner-queue stalls on chore PRs.
Without this, every PR push starts a fresh run while previous runs on
superseded commits keep executing — agents pushing 2-5 commits per
minute multiply queue pressure for zero useful signal. The conditional
`cancel-in-progress: ${{ github.event_name == 'pull_request' }}`
preserves all main-branch and scheduled work.
Variants applied per the brief:
- **default** (cancel only on PR): `benchmarks.yml`, `ci.yml`
- **compliance** (serialize, never cancel — partial reports leave
registries / attestations inconsistent): `compliance.yml`
- **release** (serialize per-tag, never cancel — partial publish
leaves npm / GitHub Release inconsistent): `release.yml`,
`release-npm.yml`. `release-npm.yml` keys on tag-name with
fallback through `inputs.version` and `github.ref` for
workflow_dispatch.
Already had correct concurrency, left alone:
- `rivet-delta.yml`: groups by `pull_request.number`, always cancels
(correct: PR-only workflow, no main runs to protect).
- `fuzz.yml`: groups by ref with `cancel-in-progress: false` (correct
for hybrid push+schedule workflow; one fuzz run per ref serializes
cleanly without losing scheduled corpus growth).
Verification before merge:
- All YAMLs parse cleanly via Python yaml.safe_load.
- Diff is workflow-files-only — no job restructure, no runs-on
change, no caching change.
Trace: skip
* ci(release-npm): drop release-npm concurrency block superseded by #261
#261 already added a concurrency block to release-npm.yml when switching
the trigger to workflow_run. Rebasing this branch on top stacked the
original release: published variant on top, producing duplicate
top-level concurrency keys (invalid YAML).
Drop the now-redundant block; #261's block (keyed on
github.event.workflow_run.head_branch) is the correct one for the
current trigger.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5 tasks
avrabe
added a commit
that referenced
this pull request
May 11, 2026
Three queued feature requests now land: rivet bundle (#266), rivet coverage --matrix (#243), s-expr linked-via operator (#265). Plus externals load their own schemas (#267) and STPA TCL numbering is corrected to ISO 26262-8 (#257). Infrastructure: CI concurrency control across all workflows (#258), migration to self-hosted smithy runners (#262), release-npm trigger fix that retroactively unblocked v0.7.0/v0.8.0 npm publication (#261), weekly dependabot (#216), and the wasmtime 42→43 upgrade that retires the RUSTSEC-2026-0114 suppression introduced in v0.8.0 (#260). #125 (provenance-lifecycle) intentionally deferred — 5-week-old branch with conflicts in heavily-churned files (CLAUDE.md, ci.yml, settings). Needs its own attention session, not safe to autonomously rebase. Refs: FEAT-001 Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 12, 2026
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