ci: add OIDC canary publish to release.yml via workflow_dispatch#1352
Merged
Conversation
npm trusted publishing allows exactly one trusted publisher per package (one repo + one workflow file), and checkly's slot is release.yml — which is why the normal release publishes via OIDC + --provenance. release-canary.yml was a separate workflow using a classic NODE_AUTH_TOKEN. That token was retired when the package moved to OIDC, so a separate workflow could no longer authenticate and the canary has failed on every PR since. Fold the canary job into release.yml so it inherits the trusted publisher: - add a `pull_request: [labeled]` trigger; the release-event jobs now gate on `github.event_name == 'release'` (PR events cascade-skip via needs: validate-tag). - the canary job publishes 0.0.0-pr.<N>.<sha> with id-token + --provenance (no token), tagged `experimental` — or a `canary:<tag>` label's tag, applied at publish time (trusted publishing authenticates `npm publish`, not a separate `npm dist-tag add`). - remove release-canary.yml.
6d1f488 to
cb1e556
Compare
Add a run-name expression so PR-label canary runs render as 'Canary build - PR #<n> (<branch>)' and release-event runs as 'Release <tag>', instead of the default commit-subject run name.
A pull_request:labeled trigger fired release.yml on every label on every PR (jobs skipped, but the release workflow was still invoked). Drop it: the canary is now a manual workflow_dispatch (`gh workflow run release.yml --ref <branch>`, optional `-f tag=`), publishing 0.0.0-canary.<sha> via the same OIDC trusted publisher. release.yml now triggers only on a real release or an explicit dispatch — never on labels. The build-label mechanism / release-canary.yml are gone.
sbezludny
approved these changes
Jun 17, 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
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.
What
Adds a manual canary publish to
release.ymlviaworkflow_dispatch, and removes the standalonerelease-canary.yml(and itsbuild-label mechanism).Why
The canary must publish from
release.ymlto use npm's OIDC trusted publisher — npm allows exactly one trusted publisher per package (one repo + one workflow file), andcheckly's isrelease.yml. The oldrelease-canary.ymlwas a separate workflow using a classicNODE_AUTH_TOKEN; that token was retired when the package moved to OIDC, so the canary has failed on every PR since.A label trigger is a non-starter:
pull_request: labeledwould firerelease.ymlon every label on every PR (jobs skip, but the release pipeline is still invoked). A manualworkflow_dispatchkeepsrelease.ymltriggered only by a real release or an explicit dispatch.Changes
release.yml: addworkflow_dispatch(inputtag, defaultexperimental) and acanaryjob (if: github.event_name == 'workflow_dispatch') that publishes0.0.0-canary.<sha>of the dispatched branch viaid-token: write+npm publish --provenance— no token. Release-event jobs gate ongithub.event_name == 'release'; dispatch runs cascade-skip them vianeeds: validate-tag.run-namedistinguishesCanary build - <branch>fromRelease <tag>in the Actions list.release-canary.yml.Usage
Verification / caveat
Depends on the
checklynpm trusted-publisher config (maintainer-owned on npmjs.com) accepting OIDC from aworkflow_dispatchrun ofrelease.yml, and not being environment-scoped to therelease/productionjob — thecanaryjob has no environment, by design. Verify with one dispatch.