# Package CI/CD: Vom Commit zum Repository

TL;DR / Management Summary In modernen Infrastrukturen bauen wir Pakete nicht mehr manuell auf dem Admin-Laptop. CI/CD Pipelines übernehmen diesen Job. In diesem Modul lernen wir, wie wir GitHub Actions oder GitLab CI nutzen, um bei jedem Code-Commit automatisch ein neues APK (Alpine) oder ZST (Arch) Paket zu bauen, es digital zu signieren und in unser internes Repository (Artikel 208) hochzuladen. Das ist die Basis für “Immutable Infrastructure” und schnelle Release-Zyklen.

# 1. Einführung & Architektur

Die automatisierte Fabrik.

Anstatt Pakete händisch zu bauen, nutzen wir Build-Container, die genau für diesen Zweck optimiert sind.

# Der CI/CD Flow (Mermaid)

graph LR
    A[Dev: git push PKGBUILD] --> B[CI Runner: Docker/Podman]
    B --> C{Build Architecture}
    C -->|x86_64| D[makepkg / abuild]
    C -->|ARM64| E[QEMU Build]
    D/E --> F[Sign Package: GPG/RSA]
    F --> G[Upload to Repo Server]
    G --> H[Update Repo Index]

# 2. Praxis: GitLab CI für Alpine (APKBUILD)

Automatisierter Build.

Datei: .gitlab-ci.yml

image: alpine:latest

build_package:
  stage: build
  before_script:
    - apk add alpine-sdk
    - adduser -D builduser && addgroup builduser abuild
    # Secret Key aus CI Variablen laden
    - echo "$ABUILD_KEY" > /home/builduser/signing-key.rsa
  script:
    - su builduser -c "abuild -r"
  artifacts:
    paths:
      - /home/builduser/packages/

# 3. Sichere Paketsignierung in der Cloud

Secrets Management.

# Automatisierter Index-Update

Nachdem das Paket gebaut wurde, muss der Repo-Server den Index aktualisieren. Dies geschieht am besten über einen Webhook oder einen remote-exec Call:

ssh repo-server "repo-add /srv/http/custom.db.tar.gz *.pkg.tar.zst"

# 4. Day-2 Operations: Multi-Arch Builds

Bauen für Intel und ARM.

Moderne Rechenzentren nutzen oft eine Mischung aus x86 und ARM (Apple Silicon, AWS Graviton).

• Nutzen Sie QEMU binfmt, um ARM-Pakete auf x86 CI-Runnern zu bauen.
• In GitHub Actions: Nutzen Sie docker/setup-qemu-action.

# 5. Troubleshooting & “War Stories”

Wenn die Pipeline rot wird.

# Story 1: “Der fehlende Build-Cache”

Symptom: Die Pipeline braucht bei jedem Durchlauf 15 Minuten, obwohl sich nur eine Zeile Code geändert hat. Ursache: Der CI-Runner lädt jedes Mal alle Abhängigkeiten und den gesamten Source-Code neu herunter. Lösung: Nutzen Sie CI-Caching für /var/cache/apk (Alpine) oder /var/cache/pacman/pkg (Arch). So werden nur neue Pakete geladen.

# Story 2: “Zertifikats-Ablauf in der CI”

Symptom: Pakete werden gebaut, aber die Installation auf den Zielservern schlägt fehl (“Invalid Signature”). Ursache: Der in der CI-Variable hinterlegte GPG/RSA-Key ist abgelaufen. Lösung: Überwachen Sie das Ablaufdatum Ihrer Signing-Keys. Nutzen Sie am besten Keys ohne Ablaufdatum für interne Build-Pipelines, solange der Zugriff auf die CI-Secrets strikt kontrolliert wird.

# 6. Fazit & Empfehlung

• Automation: Ein Paket ohne CI/CD existiert in einer Enterprise-Umgebung nicht.
• Wartbarkeit: Halten Sie Ihre APKBUILD und PKGBUILD Dateien in einem eigenen Git-Repo getrennt vom Applikationscode (Package Registry Pattern).
• Validierung: Nutzen Sie namcap (Arch) oder abuild-check (Alpine) in der Pipeline, um die Qualität der Pakete automatisch zu prüfen.

# Anhang: Cheatsheet