sbomify Action Runtimes

The tool is a CLI shipped as a container image. Configuration is environment variables, and they are identical on every platform. What changes between runtimes is only how you invoke the container, how you authenticate, and how much the platform tells the action about your build.

If your platform can run a container, it is supported - even if it does not have a page here. Start with any container runner.

Pick your platform

• GitHub Actions - native action, OIDC trusted publishing, build provenance attestation
• GitLab CI - container image, automatic VCS detection, self-managed supported
• Bitbucket Pipelines - container image via a Docker pipe, automatic VCS detection
• Jenkins - declarative and scripted pipelines, VCS from the Git plugin’s variables
• CircleCI - container executor, VCS from the job environment
• Travis CI - docker run from the job, ref from the job environment
• Azure DevOps - container job or Docker task, VCS detected from the checkout
• TeamCity - Docker Wrapper build feature or Kotlin DSL
• Any container runner - Drone, Woodpecker, Buildkite, Concourse, or a plain shell
• Local machine - uvx, pipx or Docker on your laptop

What differs

VCS auto-detect means the action records repository URL, commit SHA and branch without configuration. Yes is read from the platform’s own environment variables, with the checkout as a fallback where the vendor publishes nothing - on Jenkins a job on Subversion or Perforce, on CircleCI a job that never ran checkout. From git is read from the checkout the job is running in, which covers every CI system with no vendor integration of its own - it needs the .git directory to be present and the repository to have a remote, both of which a normal CI checkout gives you.

Vendor + git is Travis CI, which publishes the commit and the branch a build was triggered for but no repository URL - only an owner/repo slug with no host attached. The commit and ref come from the job, the URL from the checkout, and nothing is guessed from the slug.

Git roots is TeamCity, which is VCS-agnostic and can be backed by Subversion, Perforce or TFVC as easily as Git. Detection runs only when the repository URL positively identifies Git, and emits nothing otherwise rather than recording a changelist number as a commit SHA. See TeamCity.

Opt-in is a run on your own machine: it reads the checkout only when you set SBOMIFY_LOCAL_VCS=true, so an internal remote is never written into a document by accident. On every runtime, vcs_url, vcs_commit_sha and vcs_ref in sbomify.json override what was detected.

OIDC trusted publishing and attestation are GitHub-only today because both depend on GitHub-issued identity tokens. Other runtimes authenticate with an API token, and can sign with cosign rather than GitHub’s provenance tooling. Support will expand as platforms expose equivalent primitives.

The universal pattern

Every non-GitHub runtime is a variation on this:

docker run --rm \
  -v "$(pwd):/workspace" \
  -e LOCK_FILE=requirements.txt \
  -e OUTPUT_FILE=sbom.cdx.json \
  -e ENRICH=true \
  -e UPLOAD=false \
  ghcr.io/sbomify/sbomify-action

Mount your repository at /workspace - the image’s working directory, so no -w is needed - and pass configuration as environment variables. Any other mount point works as long as -w points at it, including the /github/workspace older examples used. The image entrypoint is sbomify-action, so no command is needed unless you want a subcommand such as wizard or yocto.

Whatever your platform’s syntax for “run this container with these variables” is, that is your integration.

Where the code lives

One repository, one image. There is no per-platform integration to install or keep in sync.