build(bazel): converge .bazelversion on the estate SSOT 8.2.1 - #266
Draft
Jesssullivan wants to merge 1 commit into
Draft
Jesssullivan wants to merge 1 commit into
Jesssullivan wants to merge 1 commit into
Conversation
Estate SSOT: tinyland-inc/bazel-registry docs/bazel-adoption-v0.md (TIN-3857) §1 -- "Every Tinyland repo that runs Bazel carries exactly one `.bazelversion` file at its root, pinned to the current estate-wide proven value: **8.2.1**". This repo carried 8.1.1. Also records the estate value in .bazelrc next to the registry pin, in the `# estate-bazelversion: <x.y.z>` form §5 specifies. The recording is documentation here, not a gate: this repo has no scaffold-doctor-boundary.sh bazelversion row yet, and the registry pin is still the mutable `main` ref rather than the §3 exact SHA. Both remain open and are out of scope here. No bazel-version assertion test exists in this repo to update: after this change `git grep 8.1.1` is empty, and the only other .bazelversion reference is the ci.yml cache key (hashFiles), which re-keys itself. MODULE.bazel.lock is unchanged. Its lockFileVersion is 18, the same as greatfallstoolbus.org, which already runs green on 8.2.1 -- so this move does not change the lock schema. Hosted CI is the proof.
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.
Moves this repo's root
.bazelversionfrom 8.1.1 to 8.2.1, and records that value in.bazelrc.SSOT source
tinyland-inc/bazel-registry->docs/bazel-adoption-v0.md(TIN-3857, "Bazel adoption v0 (Step A)"), read locally at/Users/jess/git/bazel-registry/docs/bazel-adoption-v0.md.§1, verbatim:
Note the doc is not in
ci-templatesand not inGloriousFlywheel— neither repo tracks a file by that name, and neither contains the stringbazel-adoption. The registry is the SSOT home.The
.bazelrcmarkerAdded, because §5 row 2 specifies the format verbatim:
So the line here is
# estate-bazelversion: 8.2.1, placed next to the registry pin as specified.What it does and does not do in this repo. It is a recording, not yet a gate. §5 makes it enforceable via
scripts/scaffold-doctor-boundary.sh, and this repo has no such row — today that row exists in exactly one repo estate-wide (greatfallstoolbus.org). And §5's phrasing assumes the value sits next to an exact-SHA registry pin; this repo still pins the mutablemainref, contrary to §3. Both gaps are real, and both are left open here deliberately: the §3 re-pin requires aMODULE.bazel.lockrefresh in the same commit, which is a separate change.Version assertion tests
None to update. After this change
git grep 8.1.1in this repo is empty. The only other.bazelversionreference is.github/workflows/ci.yml:117, ahashFiles('MODULE.bazel', '.bazelversion', 'pnpm-lock.yaml')cache key that re-keys itself — correct as-is, one cold cache fill expected.Lockfile
MODULE.bazel.lockis unchanged. ItslockFileVersionis 18 — identical togreatfallstoolbus.org, which already runs green on 8.2.1 — so 8.1.1 -> 8.2.1 does not move the lock schema. That is evidence, not proof; note.bazelrcsetscommon:ci --lockfile_mode=error, so if the bump does perturb resolution, CI fails loudly rather than silently.Proof
Hosted CI is the proof. No Bazel was run locally — this was authored on the teletype host, where bazel/bazelisk, nix, and package installs are prohibited. Nothing here is validated until this PR goes green.