Skip to content

Stamp image tags from STABLE_ status keys - #359

Merged
EdSchouten merged 1 commit into
buildbarn:mainfrom
matx-sjacob:sjacob/stable-stamp-keys
Aug 5, 2026
Merged

Stamp image tags from STABLE_ status keys#359
EdSchouten merged 1 commit into
buildbarn:mainfrom
matx-sjacob:sjacob/stable-stamp-keys

Conversation

@matx-sjacob

Copy link
Copy Markdown
Contributor

Fixes #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 behind //tools:stamped_tags is therefore never invalidated, and _stamped.tags.txt is generated once and reused indefinitely.

Ephemeral CI never sees this — each job starts with an empty cache, so the action always re-executes. On a build machine whose cache persists, every later build pushes its image to the tag produced by the first build on that machine, silently overwriting what was published there before. We hit this on a self-hosted runner: four months of builds published new content to one April tag.

A commit SHA belongs in the stable bucket. It changes rarely, and when it does, artifacts built from it should be rebuilt — which is exactly what the prefix buys.

Verification

Built //tools:stamped_tags, moved HEAD, rebuilt with nothing else touched:

build 1: HEAD=0a06012  tag=20260805T153805Z-0a06012
build 2: HEAD=5739b3f  tag=20260805T153820Z-5739b3f

The action re-runs and the tag follows the commit. Before this change it stayed frozen at the first value indefinitely.

Coordination note

bb-remote-execution, bb-remote-asset and bb-portal each ship their own tools/workspace-status.sh and consume this template via --override_module, so they need the same rename. Until they have it, their builds will emit the literal string {{STABLE_BUILD_SCM_TIMESTAMP}}-{{STABLE_BUILD_SCM_REVISION}} as the tag — visibly broken and a failed push, rather than a plausible-looking wrong tag. Happy to send the matching PRs to those repos so they can land together.

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 that builds the image tag is
therefore never invalidated, and _stamped.tags.txt is generated once and reused
indefinitely.

Ephemeral CI never sees this, since each job starts with an empty cache. On a
build machine whose cache persists, every later build pushes its image to the
tag produced by the first build on that machine, silently overwriting what was
published there before. See buildbarn#358.

A commit SHA belongs in the stable bucket: it changes rarely, and when it does,
artifacts built from it should be rebuilt.

Verified by building //tools:stamped_tags, moving HEAD, and rebuilding with
nothing else touched: the action re-runs and the tag follows the new commit.
Before this change it stayed frozen at the first value.
@EdSchouten
EdSchouten merged commit 33530b6 into buildbarn:main Aug 5, 2026
3 checks passed
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.

Image tags are stamped from non-STABLE_ status keys, so they go stale on persistent build machines

2 participants