Skip to content

Stamp image tags from STABLE_ status keys - #80

Open
matx-sjacob wants to merge 1 commit into
buildbarn:mainfrom
matx-sjacob:sjacob/stable-stamp-keys
Open

Stamp image tags from STABLE_ status keys#80
matx-sjacob wants to merge 1 commit into
buildbarn:mainfrom
matx-sjacob:sjacob/stable-stamp-keys

Conversation

@matx-sjacob

@matx-sjacob matx-sjacob commented Aug 5, 2026

Copy link
Copy Markdown

Related buildbarn/bb-storage#358

BUILD_SCM_REVISION and BUILD_SCM_TIMESTAMP have no STABLE_ prefix, so Bazel files them in volatile-status.txt and reports an unchanging digest for that file whatever it contains. The expand_template in bb-storage that turns them into the image tag is therefore never invalidated, and _stamped.tags.txt is generated once and reused indefinitely — on a build machine whose cache persists, every later build pushes its image to the tag produced by the first build on that machine.

The bb-storage bump is part of the fix: that template is what expands these keys, and the pin here predates 33530b6, which switched it to the prefixed names.

The rest follows from that bump, each uncovered by fixing the one before it:

  • .bazelversion 9.0.0rc1 → 9.1.0 — bb-storage pulls grpc@1.80.0, wanting rules_swift@2.5.0 (compatibility level 2), while the bundled bazel_tools wants 3.1.2 (level 3)
  • gazelle, googleapis, jsonnet_go, protobuf, rules_go, toolchains_llvm → the versions bb-storage builds against
  • go.mod/go.sum — the Go graph still resolved bb-storage at the old commit
  • bazel_remote_apisbecdd8f, matching what go.mod selects; while these disagreed, gazelle would not generate com_github_bazelbuild_remote_apis and bb-storage's use_repo of it failed

Verified by building @com_github_buildbarn_bb_storage//tools:stamped_tags, which now yields 20260806T094329Z-8ca266e for HEAD instead of a frozen value.

Two things for a maintainer's eye. The .github/workflows files are generated from bb-storage's template, which changed between these two pins — regenerating alters build flags and renames the release binary to bb_remote_asset.linux_amd64, so I left it out of this PR. And bb-remote-execution carries patches/bazel_remote_apis/upstream-pr-378.diff at this same commit; nothing here needs the repos it restores, so I have not added it.

@matx-sjacob
matx-sjacob marked this pull request as draft August 5, 2026 18:13
@matx-sjacob
matx-sjacob force-pushed the sjacob/stable-stamp-keys branch from 163b456 to 8ca266e Compare August 6, 2026 09:43
@matx-sjacob
matx-sjacob marked this pull request as ready for review August 6, 2026 09:48
@matx-sjacob
matx-sjacob force-pushed the sjacob/stable-stamp-keys branch 2 times, most recently from a83cd52 to 4fbd910 Compare August 6, 2026 21:49
@matx-sjacob

Copy link
Copy Markdown
Author

@EdSchouten a review on this would be much appreciated. Thanks!

@matx-sjacob
matx-sjacob force-pushed the sjacob/stable-stamp-keys branch from 4fbd910 to 18a6367 Compare August 20, 2026 15:36
BUILD_SCM_REVISION and BUILD_SCM_TIMESTAMP land in volatile-status.txt,
whose digest Bazel reports as unchanging, so the bb-storage expand_template
that turns them into the image tag is never invalidated: on a machine with
a persistent cache, every build reuses the first build's tag and silently
overwrites whatever was published there.

Rename the keys with the STABLE_ prefix and bump bb-storage to 33530b6 so
the pinned template expects the new names. The bump drags along
bazel_remote_apis (becdd8f, carrying the same upstream-pr-378.diff patch
bb-storage applies, since the root override replaces bb-storage's) and a
go.mod/go.sum refresh, with cel.dev/expr pinned back to 0.25.1 the same
way bb-storage does.

Co-Authored-By: Claude <noreply@anthropic.com>
@matx-sjacob
matx-sjacob force-pushed the sjacob/stable-stamp-keys branch from 18a6367 to b2e0bb2 Compare August 20, 2026 15:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant