CI/CD für den Neubau-Pfad

Wenn Sie die Umgebung rekonstruieren müssen, die ein betroffenes Release gebaut hat, denselben Blueprint in CI installieren, auf x86 und arm64 gleich gepinnt.

Wo CI in die Schleife passt

Zurückverfolgen endet bei einer Build-Umgebung, nicht bei einer Binary. Sobald ein Release mit dem Blueprint verknüpft ist, der es erzeugt hat, installiert sich derselbe Blueprint in CI, sodass die Pipeline, die den Patch ausliefert, dieselbe ist, die das Original gebaut hat.

Das zählt Jahre später. Die Umgebung hinter einem ausgelieferten Release lässt sich aus ihrer gepinnten Blueprint-Version rekonstruieren, jeder Toolchain-Download wird gegen seinen gepinnten Hash geprüft. Darin wird der Patch gebaut und als neues Release wieder in die Überwachung hochgeladen.

Die Version pinnen, die Sie reproduzieren müssen

Blueprints sind versioniert, daher installiert eine auf einen exakten Tag gepinnte Pipeline genau diese Umgebung und keine andere. Auf die als Build-Provenance des Releases erfasste Version pinnen, und der Neubau startet von derselben Toolchain, die die betroffene Binary erzeugt hat.

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

Caching zwischen Läufen

Installierte Umgebungen können zwischen Pipeline-Läufen gecacht werden, sodass ein Neubau nicht jedes Mal eine volle Toolchain neu herunterlädt.

Empfohlene Caching-Strategie:

• Das alloy-provisioner-Installationsverzeichnis cachen
• Blueprint-Downloads nach Version cachen
• Cache nur invalidieren, wenn sich die Blueprint-Version ändert

Beispiel-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

Was die Pipeline erzeugt

Das gepatchte Image ist das Ende des Reproduce-Zweigs und der Start des nächsten Überwachungszyklus: laden Sie es als neues Release hoch, damit der Fix inventarisiert und gescannt wird wie alles andere, was Sie ausgeliefert haben.

Build-Artefakte

Kompilierte Firmware, Binaries und Pakete

Pakete

Debian-Pakete, RPMs oder eigene Formate

Signierte Firmware

Kryptographisch signierte Images für den Update-Kanal, den der CRA verlangt

Den Neubau-Pfad in die CI bringen

Starten Sie mit einem Produkt, oder buchen Sie einen Walkthrough, wenn derselbe Blueprint in Ihrer Pipeline laufen soll.

Kostenlos starten CRA-Walkthrough buchen