Plugin manifest-version guard fires at release time, after the tag is immutable — and takes publish-installers/publish-repo with it

[kipavy]

What happened

The v0.16.0 release run failed at release / publish-plugins:

Release 'plugin-gist-sync-v1.1.0' already exists, but its index.js differ from the
freshly built bytes. plugin-gist-sync's source changed without bumping its manifest
version ... Bump the 'version' field in plugin-gist-sync's manifest.json and re-run.

The guard was right. fix(links): open the remaining dead external links via openUrl changed src/plugins/gist-sync/SettingsPage.tsx and added openExternal.ts without bumping src/plugins/gist-sync/manifest.json, so the freshly built bundle no longer matched the published plugin-gist-sync-v1.1.0 that the live catalogue points a hash at.

This is not a request to soften the check. Skipping instead of failing would ship an app whose embedded gist-sync bytes differ from what the catalogue serves, so an uninstall/reinstall would silently hand the user the old bundle back. Failing is correct.

The actual problem: where it fires

publish-plugins is needs: [changelog, publish-tauri], so the check runs only after all six desktop targets have built — ~20 minutes in, and after tag has already created an immutable v0.16.0. At that point the cheap fix (amend the offending commit) no longer exists; the bump has to land on a commit after the tag, and the shipped binary declares a version that no release matches.

The condition is a pure git-diff question — did any file under src/plugins/<id>/ change since that plugin's last published tag without manifest.json's version changing? It needs no build, no artifacts, and no release.

Blast radius, which is the part that hurt

publish-installers and publish-repo are both needs: [tag, release]. release failed, so both were skipped — Homebrew/winget and the apt/yum repo did not publish for v0.16.0 at all, and attach-plugin-catalog was skipped too. A one-line manifest omission silently took out every non-GitHub distribution channel for the release.

Proposal

1. Add the version-mismatch check to ci so a PR that edits a plugin's source without bumping its manifest fails review, not release.
2. Failing that, make it a pre-flight job in release.yml with no needs:, so it fires before tag and before 20 minutes of building.
3. Reconsider whether publish-installers / publish-repo should depend on the whole release job. A plugin-publishing failure should not be able to suppress Homebrew, winget and the Linux repos.

Remediation applied for 0.16.0

• gist-sync manifest bumped to 1.1.1 on dev (80c0e79).
• publish-plugins re-dispatched for gist-sync from that ref.
• The marketplace plugins.json merge is still the usual manual follow-up.
• Homebrew/winget and the repo publish still need re-running for v0.16.0.

[kipavy]

Additional context on point 3, which is worse than I first described.

Both publish-installers and publish-repo declare release: types: [published], so they look like they have an automatic fallback. They do not. Per their own header comments, that trigger never fires for our releases:

The release: published event does NOT fire here on its own, because that release is created by the default GITHUB_TOKEN and GitHub suppresses workflow triggers from token-authored events (anti-recursion). This workflow_call path is how new releases actually reach Homebrew/winget.

So workflow_call from tag-release.yml is the only path that has ever worked — and it is gated behind needs: [tag, release]. When release fails for any reason, including one unrelated to packaging like this plugin-manifest guard, both channels are skipped with no retry and no second trigger.

The failure mode is quiet: the GitHub release publishes and looks complete, Homebrew/winget and apt/yum silently stay on the previous version, and the only evidence is a skipped job inside a run that is already red for a different reason. v0.16.0 sat in that state until it was noticed by hand.

Worth considering alongside the fix:

• decouple publish-installers / publish-repo from the whole release job, gating them on the jobs they actually need (publish-release), not on plugin publishing
• or have them assert the published tag matches what the channel currently serves, so drift is detectable after the fact

[kipavy]

Fixed on dev — this will take effect for the next release once dev is cut into main.

PR #93 (merged to dev as ba8ed14):

1. scripts/check-plugin-versions.mjs fails when bundled source under src/plugins/<id>/ changed since that plugin's last published tag while its manifest.json version did not. It runs in ci.yml so a PR fails review, and as a plugin-versions job in tag-release.yml that tag depends on — the latter is what actually holds the "fail before the tag is immutable" property, since tag-release triggers on the same push to main and never waited for ci. Verified against the real case: reconstructed at abc8158 it exits 1 naming plugin-gist-sync, SettingsPage.tsx and openExternal.ts, so v0.16.0 would never have been tagged. The byte-comparison guard in publish-plugins.yml is untouched and remains authoritative.

2. release.yml now exposes a published output from publish-release, and tag-release.yml gates publish-installers / publish-repo on a release-published job reading it (falling back to the release's draft state, since a reusable workflow whose conclusion is failure is exactly the case that matters). A plugin failure can no longer suppress Homebrew, winget or the apt/yum repos.

Point 3 of the comment above — the dead release: types: [published] triggers — is unchanged and still dead; the explicit workflow_call path remains the only one, which is why the gating above matters.

attach-plugin-catalog still needs: publish-plugins, left deliberately: the catalogue describes the plugin releases, so that coupling is correct.

For the record, v0.16.0's fallout was cleaned up separately: gist-sync republished as 1.1.1, the catalogue updated (VoltiusApp/marketplace#10), and Homebrew/apt/rpm/winget all brought to 0.16.0 by hand.