Description
test_cargo_binstall in tests/test_image.py pins the expected version to "1.19.", but upstream released cargo-binstall 1.20.0. The Containerfile installs the latest release at build time (releases/latest), so the image now ships 1.20.0 while the test still expects 1.19.. This fails the Image Tests / Test Summary checks on open Renovate PRs (#553-556) and on dev itself.
This is not a design flaw — it is the intended version-approval gate. The same pattern applies to gh, just, taplo, and other tools installed from releases/latest: EXPECTED_VERSIONS pins are a deliberate tripwire. When upstream drifts past the pin, CI goes red and a human must consciously bump the pin and record it in the CHANGELOG (see PRs #547, #523, #525).
Steps to Reproduce
- Upstream publishes a new
cargo-binstall release (e.g. 1.20.0).
Containerfile installs the latest release at build time.- CI
Image Tests job runs test_cargo_binstall.
- The hardcoded
1.19. pin no longer matches.
Expected Behavior
Image tests fail when an upstream version drifts past the pin, prompting a human-approved bump of EXPECTED_VERSIONS and a CHANGELOG entry.
Actual Behavior
AssertionError: Expected cargo-binstall 1.19., got: 1.20.0
assert '1.19.' in '1.20.0\n'
Environment
- OS: CI (Ubuntu 24.04 host)
- Container Runtime: Podman (testinfra)
- Image Version/Tag:
ghcr.io/vig-os/devcontainer:dev
- Architecture: AMD64
Additional Context
Failing on PRs #553-556 (example job).
Follow-up: a single-source-of-truth versions file (Containerfile + tests + README) with Renovate-managed bumps would make the approval moment a reviewable PR rather than post-hoc breakage. See the linked follow-up issue.
Acceptance criteria:
Possible Solution
Bump the stale pin to 1.20. and document the version-gate intent. Longer term, centralize tool versions in a declarative file consumed by the Containerfile, tests, and README, with Renovate managing bumps.
Changelog Category: Fixed
Description
test_cargo_binstallintests/test_image.pypins the expected version to"1.19.", but upstream releasedcargo-binstall1.20.0. TheContainerfileinstalls the latest release at build time (releases/latest), so the image now ships1.20.0while the test still expects1.19.. This fails theImage Tests/Test Summarychecks on open Renovate PRs (#553-556) and ondevitself.This is not a design flaw — it is the intended version-approval gate. The same pattern applies to
gh,just,taplo, and other tools installed fromreleases/latest:EXPECTED_VERSIONSpins are a deliberate tripwire. When upstream drifts past the pin, CI goes red and a human must consciously bump the pin and record it in the CHANGELOG (see PRs #547, #523, #525).Steps to Reproduce
cargo-binstallrelease (e.g.1.20.0).Containerfileinstalls the latest release at build time.Image Testsjob runstest_cargo_binstall.1.19.pin no longer matches.Expected Behavior
Image tests fail when an upstream version drifts past the pin, prompting a human-approved bump of
EXPECTED_VERSIONSand a CHANGELOG entry.Actual Behavior
Environment
ghcr.io/vig-os/devcontainer:devAdditional Context
Failing on PRs #553-556 (example job).
Follow-up: a single-source-of-truth versions file (Containerfile + tests + README) with Renovate-managed bumps would make the approval moment a reviewable PR rather than post-hoc breakage. See the linked follow-up issue.
Acceptance criteria:
EXPECTED_VERSIONS["cargo-binstall"]from1.19.to1.20.CHANGELOG.md.cursor/rules/tdd.mdc)Possible Solution
Bump the stale pin to
1.20.and document the version-gate intent. Longer term, centralize tool versions in a declarative file consumed by the Containerfile, tests, and README, with Renovate managing bumps.Changelog Category: Fixed