[janniklasrose]

Changes

release-prs now also runs on the release event (types: [released]), so the setup-cli, homebrew-tap, VS Code extension and winget updates no longer need a manual dispatch after each release.

• A new resolve job outputs the tag (inputs.tag, or the release's tag_name on release events) and the dry-run flag (always off for release events). All jobs now read these instead of inputs.*, because inputs is empty on non-dispatch events.
• On release events, resolve only lets the downstream jobs run if the tag is the highest published (non-draft, non-prerelease) release version. If it isn't, the run is skipped with a ::notice::.
• workflow_dispatch works as before: same inputs, per-target toggles, dry run on by default, and no version check. It's still the way to retry, run a partial update, or push a release by hand.

Why

The downstream repos only follow the latest version: homebrew-tap has a single formula, VS Code bundles one CLI version, and setup-cli's @main uses the VERSION file on main. Patch releases for older versions must not move them backwards. On 2026-04-19, 86 old-version patch releases (v0.210.4 to v0.296.1) were published while v0.297.2 was the newest release. With an unguarded trigger, each of them would have opened PRs in every downstream repo.

The check compares semver against all published releases instead of using releases/latest. The "latest" flag is set by the publishing bot (oss-cli[bot]), and I couldn't confirm how it sets make_latest for backports. GitHub's default for newly published releases is true.

The trigger is released, not published, so prereleases are skipped. The release is created as a draft and published only after all assets are uploaded (for v1.23.0: assets at 12:13:11–14Z, published at 12:13:15Z), so the SHA256SUMS and Windows zips that the homebrew-tap and winget jobs read are already there. oss-cli[bot] is a GitHub App, so its publish triggers workflows; the GITHUB_TOKEN restriction doesn't apply.

For release events GitHub uses the workflow file at the tagged commit, so the first automatic run will be the first release cut after this merges.

Tests

• Ran the guard's query against the live releases. The highest version is v1.23.0, so a run for v1.23.0 would go ahead and a run for a backport like v0.296.1 would be skipped. sort -V orders v1.x above v0.299.x. All 293 published release tags are plain vX.Y.Z.
• actionlint v1.7.7: the only findings are the custom self-hosted runner label ubuntu-latest-deco, which the existing jobs already use. No expression or job-wiring errors.
• Not yet run in GitHub Actions. A dry-run dispatch from this branch would check the dispatch path. The release-event path will first run on the next release.

This pull request and its description were written by Isaac.

[eng-dev-ecosystem-bot]

Integration test report

Commit: 8b49a16

Run: 40892816651

	Env	✅​pass	🙈​skip	Time
✅​	aws linux-2core-8gb	281	15	5:36
✅​	aws-windows-latest-4core-16gb	283	13	3:23
✅​	azure linux-2core-8gb	280	15	5:29
✅​	azure-windows-latest-4core-16gb	282	13	4:53
✅​	gcp linux-2core-8gb	281	15	5:33
✅​	gcp-windows-latest-4core-16gb	283	13	3:21

Top 6 slowest tests (at least 2 minutes):

duration	env	testname
4:41	azure-windows-latest-4core-16gb	TestAccept
4:09	azure linux-2core-8gb	TestAccept
3:49	gcp linux-2core-8gb	TestAccept
3:44	aws linux-2core-8gb	TestAccept
3:18	aws-windows-latest-4core-16gb	TestAccept
3:11	gcp-windows-latest-4core-16gb	TestAccept