Skip to content

feat(cmd): the platform push carries the GitHub bill of materials - #580

Merged
thomasboni merged 2 commits into
mainfrom
feat/github-push-bom
Oct 28, 2026
Merged

thomasboni merged 2 commits into
mainfrom
feat/github-push-bom

Conversation

@thomasboni

Copy link
Copy Markdown
Contributor

Why

On a GitHub installation the platform's dependencies inventory stays empty: every GitHub push arrived without a bom section because the push built the bill of materials for GitLab runs only (platformBOMDocument returned nil for any other provider). The GitHub generator already existed for the standalone --pbom artifact. Thomas asked for it on 2026-10-27 after the demo.

What changes

  • The platform push builds the GitHub bill from the normalized workflow with the same generator the artifact uses (the composition is shared with provider/github.go, so the artifact is unchanged), under the same guards as GitLab: no section on a degraded collection, no section when there is nothing to describe, the policy runs' union as the findings source, the existing bounds and the "bill omitted, bound named" warning unchanged.
  • On GitHub the bill carries the action and reusableWorkflow includes (location, version, nested, via, archived and CVE flags, latest_version when known) and the container and service images. jobs and capabilities are empty on GitHub for now.
  • up_to_date is left absent on GitHub includes: the generator reuses that flag as a pinning indicator in the artifact, while the platform contract reads it as the CLI's verdict on currency and counts false as outdated. The CLI reaches no currency verdict on GitHub, so the key is absent there (the artifact keeps its mapping).
  • Doc comments that said "GitLab pushes only" updated; docs/platform-push-testing.md gains the GitHub case.

Checks

TDD: five GitHub bill tests (action, reusable workflow, image, degraded run, absent up_to_date) watched failing then passing; GitLab tests unchanged. make lint 0 issues, go vet clean, go test ./... 20 packages ok, the CI deadcode step (with its filters) clean.

e2e both modes: standalone GitHub on a local clone with this branch and with a build of main, out.json byte-identical, the --pbom artifact identical except generatedAt; GitLab standalone on thomasboni/test2, outputs identical. The linked push is proven by the unit test over the push body (the bill is present with its three inventories); the platform half is checked on the GitHub demo after the release.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AmKdDgroztPWz5N5LBCVzR

Comment thread cmd/platform_push.go Resolved
@thomasboni
thomasboni force-pushed the feat/github-push-bom branch from abbf4b8 to 8a6055e Compare October 28, 2026 00:37
thomasboni and others added 2 commits October 27, 2026 17:42
On a GitHub installation the platform's dependencies inventory stayed
empty: platformBOMDocument returned nil for every provider but gitlab, so
no GitHub push ever carried a bom section, although the GitHub generator
already served the --pbom artifact.

A GitHub run now pushes the section built by that same generator: the
actions as `action` includes, the job-level reusable workflow calls as
`reusableWorkflow` includes, and the job containers, services and
docker:// steps as images. The composition of the generator moves into
provider.GitHubPBOMDocument, shared by the two PBOM writers and the push,
so the artifact and the section can never disagree; the artifact output is
unchanged.

The GitLab guards apply unchanged: no section on a degraded collection, none
when the run has no workflow model to describe, the policy runs' union as
the findings source in platform mode, then platformBOMFrom and its bounds.
Every GitHub flag is a negative claim read from a finding, so an entry no
finding names keeps its three-state key out and a control nobody evaluated
claims nothing.

One field never reaches the wire on GitHub: up_to_date. The contract
defines it as the CLI's verdict on whether an include is at its latest
version, absent when the CLI reached none, and the platform stores it
verbatim as the include edge's currency flag, counting false as outdated.
The GitHub generator reuses it as a pinning indicator (false = not pinned by
SHA) and the CLI reaches no currency verdict on GitHub, so the push drops
it for every GitHub include (latest_version, the version comment, stays).
The --pbom artifact and its CycloneDX mapping keep the indicator.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AmKdDgroztPWz5N5LBCVzR
…arse

The GitHub guard read "nothing to describe" as a missing workflow model,
but the model is always set, even with zero jobs. A commit that breaks a
workflow file while workflowsMustBeValid is active is not a degraded run
(the file is a finding of its own), so the push carried a bill missing
every dependency the broken file declares, an empty one when it was the
only workflow, and the platform replaced the project's dependency edges
with it until the next good run.

A workflow file that did not parse now means the run knows nothing about
the dependencies: no section, and the platform keeps the edges as they
were. Emptiness alone is no reason: workflows that parse and declare no
action and no image, or no workflow at all, still push the empty bill,
since that run knows it has no dependencies.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AmKdDgroztPWz5N5LBCVzR
@thomasboni
thomasboni force-pushed the feat/github-push-bom branch from 8a6055e to 3b46e79 Compare October 28, 2026 00:42
@thomasboni
thomasboni merged commit a88ce02 into main Oct 28, 2026
13 checks passed
@thomasboni
thomasboni deleted the feat/github-push-bom branch October 28, 2026 00:42
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