PerishLab/ensign
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Let the client answer for its own version #62

Merged
PerishFire merged 1 commit from version-probe into main 2026-08-02 03:54:50 +00:00
Conversation 0 Commits 1 Files changed 3 +8
PerishFire commented 2026-08-02 03:50:10 +00:00
Owner
Copy link

The first release through the lane got further than expected and then failed
where it should have.

v0.2.0-beta.1 published cleanly: all three target archives built on their own
runners, the skill archive was attached, both managers were generated, and the
exact seal is served from the authority bound to commit 3791074. Publication,
public readback and verification all passed.

Smoke then failed on every platform. A generated manager stages the binary and
runs <binary> --version, comparing the answer against <name> v<version>.
The client declared disable_version_flag = true, so it printed its usage to
stderr and the probe read an empty string:

binary version mismatch: expected ensign v0.2.0-beta.1 got

Reproduced locally by fetching the published manager and installing the beta
into isolated paths, which is what smoke does.

The fix cannot read CARGO_PKG_VERSION alone: the release builds at
v0.2.0-beta.1 while the manifest still says 0.2.0. plumb::version! reads
the stamp the release build supplies and falls back to the manifest otherwise.
That is why crates/cli now depends on Plumb — the same dependency the
credential cascade will need.

Both halves verified: an ordinary build answers ensign v0.2.0, and a build
carrying ENSIGN_BUILD_VERSION answers with the stamped version.

Guard is clean on the committed state, including all six acts.

The first release through the lane got further than expected and then failed where it should have. `v0.2.0-beta.1` published cleanly: all three target archives built on their own runners, the skill archive was attached, both managers were generated, and the exact seal is served from the authority bound to commit `3791074`. Publication, public readback and verification all passed. Smoke then failed on every platform. A generated manager stages the binary and runs `<binary> --version`, comparing the answer against `<name> v<version>`. The client declared `disable_version_flag = true`, so it printed its usage to stderr and the probe read an empty string: ``` binary version mismatch: expected ensign v0.2.0-beta.1 got ``` Reproduced locally by fetching the published manager and installing the beta into isolated paths, which is what smoke does. The fix cannot read `CARGO_PKG_VERSION` alone: the release builds at `v0.2.0-beta.1` while the manifest still says `0.2.0`. `plumb::version!` reads the stamp the release build supplies and falls back to the manifest otherwise. That is why `crates/cli` now depends on Plumb — the same dependency the credential cascade will need. Both halves verified: an ordinary build answers `ensign v0.2.0`, and a build carrying `ENSIGN_BUILD_VERSION` answers with the stamped version. Guard is clean on the committed state, including all six acts.
Let the client answer for its own version
All checks were successful
guard / guard (pull_request) Successful in 3m40s
Details
guard / guard (push) Successful in 3m35s
Details
c081017053 
The first release through the lane published four artifacts and both managers,
then failed smoke on every platform: a generated manager runs `<binary>
--version` and compares the answer to `<name> v<version>`. The client had
`disable_version_flag = true`, so it printed usage to stderr and the probe read
an empty string.

The version cannot come from CARGO_PKG_VERSION alone, because a release is
built at v0.2.0-beta.1 while the manifest says 0.2.0. plumb::version! reads the
stamp the release build supplies and falls back to the manifest otherwise,
which is why the client now depends on Plumb at all.

Verified both halves: an ordinary build answers `ensign v0.2.0`, and a build
carrying ENSIGN_BUILD_VERSION answers with the stamped version.
PerishFire deleted branch version-probe 2026-08-02 03:54:50 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
PerishLab/ensign!62
No description provided.