Article 14 reporting starts 11 September 2026.See what you need in place

CI/CD for the rebuild path

When you must reconstruct the environment that built an affected release, install the same blueprint in CI, pinned the same way on x86 and arm64.

Where CI fits in the loop

Trace back ends at a build environment, not at a binary. Once a release is linked to the blueprint that produced it, the same blueprint installs in CI, so the pipeline that ships the patch is the pipeline that built the original.

That matters years later. The environment behind a release you shipped can be reconstructed from its pinned blueprint version, with every toolchain download checked against its pinned hash, then used to build the patch and upload it as a new release back into monitoring.

Pin the version you must reproduce

Blueprints are versioned, so a pipeline pinned to an exact tag installs that environment and no other. Pin to the version recorded as the release's build provenance and the rebuild starts from the same toolchain that produced the affected binary.

alloy-provisioner install --docker community/raspberry-pi/raspberry-pi-5:1.0.3

Caching between runs

Installed environments can be cached between pipeline runs, so a rebuild does not re-download a full toolchain every time.

Recommended caching strategy:

  • • Cache the alloy-provisioner installation directory
  • • Cache blueprint downloads by version
  • • Invalidate the cache only when the blueprint version changes

Example Pipeline Snippets

GitHub Actions

name: Build Firmware

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - name: Install alloy-it Environment
        run: |
          alloy-provisioner install community/raspberry-pi/raspberry-pi-5:1.0.3
          
      - name: Build Firmware
        run: |
          source alloy-env.sh
          make firmware
          
      - name: Upload Artifacts
        uses: actions/upload-artifact@v7
        with:
          name: firmware
          path: build/firmware.bin

GitLab CI

build_firmware:
  image: ubuntu:22.04
  script:
    - apt-get update && apt-get install -y curl
    - curl -fsSL https://raw.githubusercontent.com/alloy-it/alloy-provisioner-releases/main/scripts/install.sh | bash
    - alloy-provisioner install community/raspberry-pi/raspberry-pi-5:1.0.3
    - source alloy-env.sh
    - make firmware
  artifacts:
    paths:
      - build/firmware.bin

What the pipeline produces

The patched image is the end of the reproduce leg and the start of the next monitoring cycle: upload it as a new release so the fix is inventoried and scanned like everything else you shipped.

Build artifacts

Compiled firmware, binaries, and packages

Packages

Debian packages, RPMs, or custom formats

Signed firmware

Cryptographically signed images for the update channel the CRA requires

Get the rebuild path into CI

Start with a product, or book a walkthrough if you want the same blueprint in your pipeline.