SBOM further issue fixes - #947
Open
filipleple wants to merge 3 commits into
Open
Conversation
Commit e0813b3 converted most git-backed SBOM components to the human-readable `<date>_<hash>` software-version and a release tag as colloquial-version, but edk2-platforms and edk2-gop were missed and still emitted a bare commit hash with a tree hash as colloquial-version. openSIL likewise still recorded only a bare commit hash. Convert all three to follow suit: software-version now uses `<commit-date>_<hash>`, and where the template carries a colloquial-version field (edk2-platforms, edk2-gop) it now holds the latest release tag reachable from HEAD, selected the same way as the iPXE/vboot rules. openSIL has no colloquial-version field, so only its software-version changes. Decisions based on the RFC: https://datatracker.ietf.org/doc/rfc9393/ Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
filipleple
force-pushed
the
sbom_issuefixes
branch
from
July 24, 2026 10:15
7d05309 to
3ff4d68
Compare
SergiiDmytruk
previously approved these changes
Jul 25, 2026
Every git-backed SBOM component derived its two version fields by hand-rolling the same two git commands, spelled three different ways (`--git-dir <repo>/.git`, `-C <dir>`, implicit cwd), with inconsistent stderr redirection and safe.directory handling. The latest-release tag alone was open-coded at five call sites, so changing how it is obtained meant a five-place edit. Introduce three `$(call)` helpers in the established strip_quotes idiom - sbom-git-comm-hash, sbom-git-latest-rel and sbom-git-toplevel-of - and route all call sites through them, so each git operation has exactly one definition. safe.directory is now relaxed uniformly rather than only for openSIL; containerized builds need it everywhere. With the command in one place, replace the open-coded `tag --merged HEAD --sort=-creatordate | head -n1` with the equivalent `git describe --tags --abbrev=0`, as suggested in review. Two flags are load-bearing: --tags is required because some component repositories (iPXE) carry only lightweight tags, which git describe ignores by default, and `|| true` is required because git describe exits 128 on repositories with no tags at all (3rdparty/vboot, 3rdparty/blobs), which would abort the recipes running under `set -e`. Output was verified identical for every checked-out component repository. coreboot.json deliberately keeps its own `^NN.NN$` tag filter: forks carry their own release tags, and git describe would return those (e.g. novacustom_nuc_box_v0.9.2) instead of the coreboot release. The comment there now says so, so a later cleanup does not "fix" it. No SBOM output changes. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
philipanda
reviewed
Aug 5, 2026
Match point-release tags (24.02.01, 4.20.1) so a fork based on a release branch reports its real base, and abort instead of emitting an empty colloquial-version when the checkout carries no release tag at all, as happens on a shallow or blobless clone made without --tags. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
philipanda
approved these changes
Aug 6, 2026
SergiiDmytruk
approved these changes
Aug 6, 2026
Comment on lines
+260
to
+261
| # omitted field, unlike the tagless third-party repositories handled by | ||
| # sbom-git-latest-rel: for coreboot itself the release is always there to find. |
Member
There was a problem hiding this comment.
unlike the tagless third-party repositories handled by sbom-git-latest-rel
This doesn't sound right, sbom-git-latest-rel is used to find tags.
Contributor
There was a problem hiding this comment.
I think it was supposed to mean that sbom-git-latest-rel also handles the situation when there are no tags, but I don't think it's the case. It just prints nothing if there are no tags. That's not handling, that's ignoring the issue.
On the other hand it might have meant that it's the only place where we verify the tag exists, because we know coreboot has tags. Failing if theres no tag in repos with no tags wouldn't be right. But just like coreboot, we know whether tags exist or not on all of the repos used here, so why not just make it explicit.
I agree this sentence could be better.
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
3 participants
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.
ref: sha-1717