docs: VCS detection everywhere, and /workspace is the mount - #147
Merged
vpetersson merged 2 commits intoSep 1, 2026
Merged
Conversation
Catches the sbomify-action docs up with the CI runtime platform layer (sbomify-action#401) and the audit trail path change (#400). VCS metadata is no longer a GitHub/GitLab/Bitbucket/TeamCity feature. Platforms that publish no repository variables now read the git checkout, so Jenkins, CircleCI, Azure Pipelines and any other container runner get provenance with no configuration -- the pages for all four told people to hand-write vcs_url into sbomify.json. A local run is the exception: it reads the checkout only under SBOMIFY_LOCAL_VCS=true, so an internal remote does not end up in a document that leaves the company. The image gained WORKDIR /workspace, so every docker run example loses its -w. The old `-v "$PWD:/github/workspace" -w /github/workspace` still resolves and the generic runner page says so, along with the trap that comes with it: outputs are written relative to the working directory, so a mount without a matching -w leaves the SBOM inside the container. TeamCity's `-w /github/workspace` was wrong before this branch and is gone from all four places it appeared. The Docker Wrapper mounts the checkout and runs the script inside it; overriding -w pointed the run at a directory that is not the checkout, which the same page contradicted two paragraphs later. Also: Bitbucket Data Center gets no guessed commit URL, the wizard refuses on any recognised CI platform rather than $CI and $GITHUB_ACTIONS alone, WORKING_DIR confinement is GitHub Actions only, and audit trail paths are recorded relative to the working directory. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KpQTA8RTVfX4wm5is4S4MQ
Conflicts were all the same shape: upstream dropped the inert `section: sbomify-action` frontmatter key (491f65f) on the four runtime pages whose adjacent `tldr` this branch rewrote. Kept both changes -- no `section:` key, and the tldr that says VCS details are detected rather than hand-written. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KpQTA8RTVfX4wm5is4S4MQ
vpetersson
approved these changes
Sep 1, 2026
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.
Catches the
/sbomify-action/docs up with the CI runtime platform layer (sbomify-action#401) and the audit trail path change (#400).What was wrong
VCS detection is no longer a GitHub/GitLab/Bitbucket/TeamCity feature. Platforms that publish no repository variables now read the git checkout, so Jenkins, CircleCI, Azure Pipelines and any other container runner get provenance with no configuration. All four pages told people to hand-write
vcs_urlintosbomify.json. A local run is the exception: it reads the checkout only under the newSBOMIFY_LOCAL_VCS=true, which we did not document at all.The image gained
WORKDIR /workspace, so everydocker runexample loses its-w. The old-v "$PWD:/github/workspace" -w /github/workspacestill resolves and the generic runner page says so, along with the trap that comes with it: outputs are written relative to the working directory, so a mount without a matching-wleaves the SBOM inside the container.TeamCity's
-w /github/workspacewas wrong before this branch and is gone from all four places it appeared. The Docker Wrapper mounts the checkout and runs the script inside it; overriding-wpointed the run at a directory that is not the checkout — which the same page contradicted two paragraphs later.Also corrected: Bitbucket Data Center gets no guessed commit URL, the wizard refuses on any recognised CI platform rather than
$CIand$GITHUB_ACTIONSalone,WORKING_DIRconfinement is GitHub Actions only, and audit trail paths are recorded relative to the working directory.Files
augmentation.md— rewrote Automatic VCS detection: source table, the two preconditions for checkout-based detection,SBOMIFY_LOCAL_VCS, commit-URL coverage_index.md,runtimes/_index.md— matrices (Manual→From git, local →Opt-in), universal pattern mounts/workspaceruntimes/{jenkins,circleci,azure-devops,local,docker,bitbucket}.md— VCS sections and the frontmatter tldrs that promised manual config; new VCS section on the generic Docker page covering theCI/vendor-variable requirementruntimes/teamcity.md— dropped the stale-wconfiguration.md—SBOMIFY_LOCAL_VCS,DISABLE_VCS_AUGMENTATION,WORKING_DIR, generic CI vendor/checkout variablesquickstart.md,advanced.md,github-actions.md,how-it-works.md— mount paths, wizard CI note, audit-trail path notebun run lintpasses andhugo --minify --environment productionbuilds clean.🤖 Generated with Claude Code
https://claude.ai/code/session_01KpQTA8RTVfX4wm5is4S4MQ