Repository navigation
fix: record the base digest of a BlueBuild slot - #764
Merged
Merged
Conversation
`bluebuild generate` pins the base by digest (`FROM <repository>@sha256:...`), so after a BlueBuild build the base is in local storage under that digest and not under its tag. The digest was read by inspecting the tag, which found nothing: the first hosted run's budgie-atomic (BlueBuild) slot recorded an empty base digest, and a failure issue would have said "not recorded". The digest is now read from the reference the built Containerfile pulled the base by: the tag for the Containerfile method, the pinned digest for BlueBuild. Signed-off-by: Douglas Baggett <doug.baggett@gmail.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
danathar-atomic-hive
Bot
added
author/clanker
Danathar
added a commit
that referenced
this pull request
Oct 18, 2026
…ded (#765) #764 looked for the base in the rendered Containerfile, but BlueBuild names it through an ARG (`ARG BASE_IMAGE="<repository>@sha256:..."`, then `FROM "${BASE_IMAGE}"`), so the lookup fell back to the tag and the dispatched BlueBuild run still recorded no base digest. Its test fed the expanded form, which only the build log shows. podman prints every FROM step with its ARGs expanded, so the reference is now read from build.log. Replaying both hosted runs' build logs gives the pinned digest for budgie-atomic (BlueBuild) and the tag for bazzite-dx-gnome (Containerfile). Signed-off-by: Douglas Baggett <doug.baggett@gmail.com>
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
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.
The first hosted run of the variant boot test (run 39123468770) passed both slots, but the BlueBuild slot (budgie-atomic) recorded an empty
base_digest. A failure issue for a BlueBuild slot would have shown "Base digest: not recorded".Why
bluebuild generatepins the base by digest. That run's build log starts withFROM quay.io/fedora-ostree-desktops/budgie-atomic@sha256:5be0a50e… AS variant-budgie-atomic, so after the build the base is in local storage under that digest and not under its tag.run_slotread the digest by runningpodman image inspecton the tag, which finds nothing.Change
base_reference()returns the reference the built Containerfile pulled the base by. For the Containerfile method that is the tag; for BlueBuild it is the pinned digest.run_slotinspects that reference.FROMshape from that run resolves to the pinned digest.How it was checked
python3 -m unittest discover -s tests(2587 tests),ruff check,git diff --check.image not knownwhen inspected by its tag, and returns its digest when inspected by the digest reference.