feat(version): name the running and available build in check #151

Merged

Claude-Run merged 1 commit from feat/YT-94-version-check-build-identity into main

2026-08-10 20:58:58 +02:00

Claude-Run commented

2026-08-10 20:57:54 +02:00

Member

yt version check identified a build by the least it could get away with: the latest train quoted only the bare commit and the release train only the two semvers, and nothing at all was known about the build yt version update would install, because the registry published only the binary and its .sha256 checksum.

Each build workflow now writes and publishes an <artifact>.json metadata sidecar beside the binary and its checksum, carrying version / commit / build_date / train from the values it already passes as build args, through the same DELETE-ignoring-404-then-upload sequence and printed in the same "Print published URLs" step. check fetches that sidecar from the URL the current train would install from (/latest/<artifact> or /v<semver>/<artifact>) and renders both builds through version::build_banner, the helper that also produces LONG_VERSION's shape, so the running banner and the remote banner cannot drift.

Missing metadata is never an error and never blocks the verdict: a non-2xx (every artifact published before this sidecar existed 404s) or an unparseable body drops the available: line, logs the reason at debug, and exits 0, while a registry that cannot be reached at all still reports the existing "Could not check for updates from the package registry" diagnostic. The verdicts are unchanged and stay independent of the metadata: the latest train compares checksum digests, the release train compares semvers, and no path compares build dates.

describe_latest's no-version-number rule is narrowed rather than dropped: the semver may appear as one component of a full build banner, never as a standalone freshness claim, and the test that encoded the old rule now asserts the narrower one. crates/yt-cli/tests/ci_metadata_sidecar.rs fails the build if a workflow stops writing or publishing the sidecar.

#YT-94

`yt version check` identified a build by the least it could get away with: the latest train quoted only the bare commit and the release train only the two semvers, and nothing at all was known about the build `yt version update` would install, because the registry published only the binary and its `.sha256` checksum. Each build workflow now writes and publishes an `<artifact>.json` metadata sidecar beside the binary and its checksum, carrying `version` / `commit` / `build_date` / `train` from the values it already passes as build args, through the same DELETE-ignoring-404-then-upload sequence and printed in the same "Print published URLs" step. `check` fetches that sidecar from the URL the current train would install from (`/latest/<artifact>` or `/v<semver>/<artifact>`) and renders both builds through `version::build_banner`, the helper that also produces `LONG_VERSION`'s shape, so the running banner and the remote banner cannot drift. Missing metadata is never an error and never blocks the verdict: a non-2xx (every artifact published before this sidecar existed 404s) or an unparseable body drops the `available:` line, logs the reason at debug, and exits 0, while a registry that cannot be reached at all still reports the existing "Could not check for updates from the package registry" diagnostic. The verdicts are unchanged and stay independent of the metadata: the latest train compares checksum digests, the release train compares semvers, and no path compares build dates. `describe_latest`'s no-version-number rule is narrowed rather than dropped: the semver may appear as one component of a full build banner, never as a standalone freshness claim, and the test that encoded the old rule now asserts the narrower one. `crates/yt-cli/tests/ci_metadata_sidecar.rs` fails the build if a workflow stops writing or publishing the sidecar. #YT-94

Claude-Run added 1 commit

2026-08-10 20:57:54 +02:00

feat(version): name the running and available build in check

Check / fmt + clippy + build + tests (pull_request) Successful in 32s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

e31817a2e7

`yt version check` identified a build by the least it could get away with: the latest train quoted only the bare commit and the release train only the two semvers, and nothing at all was known about the build `yt version update` would install, because the registry published only the binary and its `.sha256` checksum.

Each build workflow now writes and publishes an `<artifact>.json` metadata sidecar beside the binary and its checksum, carrying `version` / `commit` / `build_date` / `train` from the values it already passes as build args, through the same DELETE-ignoring-404-then-upload sequence and printed in the same "Print published URLs" step. `check` fetches that sidecar from the URL the current train would install from (`/latest/<artifact>` or `/v<semver>/<artifact>`) and renders both builds through `version::build_banner`, the helper that also produces `LONG_VERSION`'s shape, so the running banner and the remote banner cannot drift.

Missing metadata is never an error and never blocks the verdict: a non-2xx (every artifact published before this sidecar existed 404s) or an unparseable body drops the `available:` line, logs the reason at debug, and exits 0, while a registry that cannot be reached at all still reports the existing "Could not check for updates from the package registry" diagnostic. The verdicts are unchanged and stay independent of the metadata: the latest train compares checksum digests, the release train compares semvers, and no path compares build dates.

`describe_latest`'s no-version-number rule is narrowed rather than dropped: the semver may appear as one component of a full build banner, never as a standalone freshness claim, and the test that encoded the old rule now asserts the narrower one. `crates/yt-cli/tests/ci_metadata_sidecar.rs` fails the build if a workflow stops writing or publishing the sidecar.

#YT-94