chore: resolve latest bincraft release dynamically (no hardcoded pins) #107
Loading…
Reference in a new issue
No description provided.
Delete branch "chore/dynamic-bincraft-version"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Stop hardcoding the bincraft version. Every
.crowworkflow and the build-one image pinned@vX.Y.Z(and apackageVersion() != "X.Y.Z"guard), so each bincraft release meant editing the version in ~8 places — and it was easy to miss one (the Dockerfile lagged at v4.2.1; v4.4.1 shipped without the empty-env fix because of exactly this churn).Change
New
local/install-bincraft.Rresolves the latest release tag dynamically:git ls-remote --tagson the public repo (no token),vX.Y.Ztags, pick the highest version (filtered/sorted in R for portability, not via git--sort/refspec which behaved inconsistently undersystem2()),pak::pak("git::…@<latest>")— idempotent on the git ref, so re-runs keep the package unless a newer tag exists.All call sites now invoke the helper instead of a pinned version:
.crow/build-all-versions.yaml(primary + per-minor pass).crow/build-all-versions-install-deps.yaml.crow/process-updates.yaml(primary + per-minor pass).crow/weekly-rebuild-missing.yaml.crow/archive-missed-packages.yamldocker/build-one.Dockerfile(ships the helper into the image;ensure_bincraftsources it)Effect
Tag a new bincraft release → the next CI run /
just rebuildpicks it up automatically. No more pin edits, and no more "forgot to bump the Dockerfile" drift.Verified
v4.4.2) viagit ls-remote+ R-side version sort.Note: this tracks the latest tag, so cutting a release is still the deliberate gate — CI won't pick up un-tagged main.