fix(ci,ca-149): release-please dispatch fallback + vscode prerelease default#39
Merged
fix(ci,ca-149): release-please dispatch fallback + vscode prerelease default#39
Conversation
…default
Two related papercuts fixed:
1. CA-149 token gap (the documented "tags don't trigger downstream workflows
when release-please uses GITHUB_TOKEN" problem) now self-heals via
workflow_dispatch:
- oss-release.yml + build-images.yml gain a workflow_dispatch trigger
(additive; push:tags still works when RELEASE_PLEASE_TOKEN is provisioned)
- release-please.yml gains a trailing dispatch step that, after
release-please creates the root component's tag, invokes
`gh workflow run oss-release.yml --ref <tag>` and
`gh workflow run build-images.yml --ref <tag>` via the default
GITHUB_TOKEN — workflow_dispatch is exempt from the recursion guard
that blocks push:tags chains, so this fires cleanly.
- The dispatch step is a no-op when secrets.RELEASE_PLEASE_TOKEN is set
(avoids double-runs on top of the canonical-token tag push). The
plugin component (sourcebridge-vscode-vX.Y.Z tags) is intentionally
skipped since it's filtered out of both downstream workflows by tag
glob anyway.
2. release-please-config.json adds `"prerelease": true` to the vscode
plugin component. The recently-cut `sourcebridge-vscode-v0.3.1` was
created as a non-prerelease, non-draft release, which made it the
project's "Latest" pointer (v0.10.0-rc.3 was a draft, v0.9.0-rc.3 was
prerelease, so the plugin won by default). The plugin is pre-1.0 and
should always be prerelease until it stabilizes; doing it via config
prevents the next plugin release from re-triggering the same flag
confusion.
The existing `sourcebridge-vscode-v0.3.1` release was manually fixed
out-of-band via `gh release edit --prerelease`; this commit prevents
recurrence.
Tracked: CA-149 (canonical fix is still to provision RELEASE_PLEASE_TOKEN
per RELEASING.md; this commit makes the bootstrap state self-healing
until that's done).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.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
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
Fixes two related release-pipeline papercuts:
1. CA-149 — release-please tag pushes don't trigger downstream workflows
The repo already documents the canonical fix (provision
RELEASE_PLEASE_TOKENGitHub App / PAT perRELEASING.md), but the bootstrap state — using the defaultGITHUB_TOKEN— leaves releases half-published: tag created, butoss-release.yml(binary build, GitHub release publish) andbuild-images.ymldon't fire because GitHub deliberately suppresses workflow-on-workflow chains driven byGITHUB_TOKEN.This PR makes the bootstrap state self-healing without requiring any token provisioning:
oss-release.yml+build-images.ymlgain aworkflow_dispatchtrigger (additive; existingpush:tagscontinues to work)release-please.ymlgains a trailing step that, when the root component cuts a tag, dispatches both downstream workflows viagh workflow run --ref <tag>—workflow_dispatchevents are exempt from the GITHUB_TOKEN recursion guard, so this works with the default tokenRELEASE_PLEASE_TOKENis provisioned (avoids double-runs on top of the canonical-tokenpush:tags)sourcebridge-vscode-vX.Y.Z) are intentionally not dispatched — they're already filtered out of both downstream workflows by tag glob2. vscode plugin auto-prerelease
The just-cut
sourcebridge-vscode-v0.3.1release was created withisPrerelease: false, which made it the project's "Latest" pointer (v0.10.0-rc.3 was still a draft awaitingoss-release.yml; v0.9.0-rc.3 was correctly prerelease; the plugin won by default).release-please-config.jsonnow sets"prerelease": trueon the vscode plugin component. The plugin is pre-1.0 and should remain prerelease until it stabilizes. The existingsourcebridge-vscode-v0.3.1release was already fixed manually viagh release edit --prerelease; this prevents recurrence on future plugin releases.Test plan
python3 -c "import yaml; yaml.safe_load(open(p))"for all 3 workflow files)release-please-config.jsonRELEASE_PLEASE_TOKENgets provisioned later, the dispatch step'sRELEASE_PLEASE_TOKEN_PRESENTcheck skips fallback dispatch — confirm no double-run🤖 Generated with Claude Code