Running in CI/CD

This guide covers using lynkctl as a build step that generates an SBOM and, optionally, gates the pipeline on SBOM quality.

Making lynkctl Available

lynkctl is distributed by Interlynk — see Installation. In CI, make the binary available to the runner the same way you handle other internal tooling: a prebuilt container image, an internal artifact store, or a cached binary. The examples below assume lynkctl is already on PATH.

---

Quality Gate with Strict Mode

--strict makes lynkctl exit 1 when any warning-level diagnostic is present. Use it to block releases whose SBOMs are incomplete or uncertain:

lynkctl generate . --strict -o sbom.cdx.json

The SBOM is still written before lynkctl exits non-zero, so you can archive it for inspection even on a failed gate.

GitHub Actions

name: SBOM
on: [push, pull_request]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM
        run: lynkctl generate . --strict -o sbom.cdx.json

      - name: Upload SBOM
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json

The if: always() on the upload step keeps the SBOM as an artifact even when the strict gate fails.

GitLab CI

sbom:
  stage: test
  script:
    - lynkctl generate . --strict -o sbom.cdx.json
  artifacts:
    when: always
    paths:
      - sbom.cdx.json

Refreshing the OSS-Index Database

If your runners cache the OSS-index database, refresh it only when it is stale. db check exits 0 when current and 1 when not:

lynkctl db check || lynkctl db download

For runners without network access, see Air-Gapped Environments.

Reproducible Pipeline Output

To produce byte-identical SBOMs across rebuilds of the same source — useful for content-addressable storage and diffing — add --reproducible. See Reproducible SBOMs.

Related

• Diagnostics & Exit Codes — interpret the exit code and warnings

• Air-Gapped Environments — CI without network access