release: the version check expects the name the artifact ships as - #277
Merged
Conversation
`verify-release-version.sh` asserted the built binary reports `mobee <version>`. The binary answers to `maxplayer`: `[[bin]] name` and `[package] name` are deliberately different, so the assertion was comparing against the crate name. Every platform's `Verify the version matches the release` step failed immediately after its `Build` step succeeded (run 30501403283). The expected name is now derived from the basename of the path the workflow is about to package, so it follows the binary instead of restating it. Six residual-grep forms of the old binary name were swept before the rename landed — `bin/`, `release/`, `/b/`, `mainProgram`, `apps.*.program`, the arm64 version grep — and none of them could match a name written inside a quoted equality test. This also adds coverage the literal never had: an artifact shipped under a name it does not answer to now fails, which is the hazard the constructed asset filename guards against upstream. The stale artifact case the check exists for is unchanged. Red-proved against the real script with a stubbed cargo and stub binaries: correct artifact passes, tree-only passes, and it fails on `mobee 0.1.0` at a `maxplayer` path, on version `0.2.0`, and on a binary shipped as `runner` that answers to `maxplayer`.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
orveth
pushed a commit
that referenced
this pull request
Jul 30, 2026
This was referenced Jul 30, 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.
Unblocks the release pipeline. Dry-run #5 (run
30501403283, main433fcea) failed on all threeplatforms at
Verify the version matches the release, immediately after eachBuildsucceeded:The binary is right and the verifier was wrong.
verify-release-version.shcompared against ahardcoded
"mobee $VERSION", which is the crate name; the binary answers tomaxplayer, because[[bin]] nameand[package] nameare deliberately different and the store path staysmobee-0.1.0.Why the rename audit could not have caught it
The rename was swept for residual forms of the old binary name —
bin/mobee,release/mobee,/b/mobee,mainProgram "mobee",apps.*.program, the arm64^mobeeversion grep. That sweep wascorrect and it was complete for the forms it enumerated. This site names the binary inside a quoted
shell equality test,
[ "$reported" = "mobee $VERSION" ]— a seventh form, adjacent to none of thesix, and invisible to a path-shaped grep. The file's own usage comment already read
result/bin/maxplayer: the documentation had been renamed and the assertion had not.The fix
The expected name is derived from the basename of the path the workflow is about to package, so it
follows the binary rather than restating it:
A literal here silently commits to one of two deliberately-different names and goes stale the moment
either moves — which is precisely how this check came to expect
mobeefrom a binary that correctlyanswers to
maxplayer.It also adds coverage the literal never had: an artifact shipped under a name it does not answer to
now fails. That is the same hazard the constructed asset filename guards against upstream — a runner
published under the racer's package name would install, run, and be the wrong program.
Red-proved, not asserted
cargois absent on the seat that wrote this, socargowas stubbed (the script only ever readsmanifest metadata from it, never builds) and the real script was run end-to-end against real npm
manifests and stub binaries — a green control plus three distinct reds, including one for the failure
this PR fixes and one for the failure the check already existed to catch:
Base is
main, deliberatelyDry-runs are
workflow_dispatchagainstmainand read the scripts from the dispatched ref, so thefix has to be on
mainto re-run dry-run #5.dev == mainright now, so a back-merge (fast-forward)restores
main ⊆ devimmediately after — the same shape used for #270.Not a release. Nothing here can publish:
release.ymlhas no branch trigger (push: tags: ['v*']plus
workflow_dispatch), and both publishing jobs are gatedgithub.event_name == 'push' && github.ref_type == 'tag'.Verified nearby, needing no change
npm/mobee/declares namemaxplayerwith binmaxplayer, and theplatform packages are
@maxplayerai/linux-x64/@maxplayerai/linux-arm64withbin/maxplayer. Sonpx maxplayerresolves once published; the directory name is cosmetic.t=mobeestays —MOBEE_TAGingateway.rsand the twokinds.jsfiles is a nostr wirevalue, not a display name. Renaming it would break interop with every live seat.
cargo metadata'sp.name === "mobee"lookup in this same script is correct and untouched: that onereally is the crate.