Skip to main content
Deutsch  •  English  •  Español  •  Français  •  Italiano  •  Polska  •  Portuguese  •  Български  •  Русский  •  Українська  •  やまと  •  中国  •  فارsi

⚙️ Integrazione continua (CI): Hammers, Furnace e Incubator

L'infrastruttura di Continuous Integration di penguins-eggs (.github/workflows/) è suddivisa in tre pipeline specializzate. La divisione nasce da un'osservazione ingegneristica precisa: la pacchettizzazione è un lavoro user-space che gira felicemente nei container ospitati da GitHub, mentre la rimasterizzazione live e il collaudo dell'installazione su disco richiedono un kernel reale, mount point fisici, dischi virtuali e il controllo di un hypervisor Proxmox VE.

PipelineWorkflowDove giraCosa produce / collauda
🔨 Hammershammers.ymlRunner GitHub (container)Compilazione e pacchetti nativi (.apk, .pkg.tar.zst, .deb, .rpm).
🏭 Furnacefurnace.ymlSelf-hosted runner + Proxmox VEVoli completi sudo eggs remaster che sfornano ISO live avviabili.
🐣 Incubatorincubator-go.ymlSelf-hosted runner + Proxmox VECollaudo automatico di installazione delle ISO su disco (krill su ext4/btrfs, BIOS/UEFI).

🔨 1. Hammers: la matrice di pacchettizzazione​

Ad ogni push o pull request su main, Hammers avvia in parallelo (fail-fast: false) un container per ciascuna famiglia supportata (Alpine, Arch Linux, Manjaro, Debian, Fedora, openSUSE):

  1. Allestimento della bottega: installa la toolchain nativa (GCC, Go, Make, tool di packaging) e crea l'utente non privilegiato artisan.
  2. Compilazione e Packaging: esegue make (compilando oa in C e coa in Go) e lancia make package come utente artisan, generando il pacchetto nativo tramite abuild, makepkg, dpkg o rpmbuild.
  3. Smoke Test Live: installa il pacchetto appena forgiato direttamente dentro il container per verificarne metadati e dipendenze, caricandolo poi come artefatto della release.

Domanda a cui risponde Hammers: «Il codice compila e genera un pacchetto nativo valido su tutte le famiglie supportate?»

🏭 2. Furnace: rimasterizzazione sul ferro reale (Proxmox VE)​

Eseguita su un runner self-hosted collegato al nodo Proxmox VE (father), Furnace mappa ogni distribuzione (Alpine, Arch, Debian, Devuan, Fedora, Manjaro, openKylin, openSUSE, Ubuntu) su una macchina virtuale KVM dedicata dotata di uno snapshot pulito (virgin):

  1. Rollback & Boot: riporta la VM allo snapshot virgin (qm rollback + qm start), garantendo che ogni volo parta da un sistema incontaminato.
  2. Scoperta IP dinamica e SSH: legge il MAC address da qm config, individua l'IP via ARP sweep ed entra in SSH.
  3. Installazione e Volo: scarica l'ultimo pacchetto di penguins-eggs, lo installa ed esegue sudo eggs remaster su un kernel reale con veri mount OverlayFS.
  4. Esportazione e Spegnimento: trasferisce la ISO generata sullo storage Proxmox tramite eggs export iso --clean e spegne la VM (if: always()).

Domanda a cui risponde Furnace: «L'intera catena di remastering produce effettivamente una ISO live avviabile su ogni distribuzione?»

🐣 3. Incubator: collaudo di installazione automatica (incubator-go)​

Una ISO generata non è davvero validata finché non viene installata su un disco e riavviata. Incubator utilizza incubator-go — un orchestratore in Go a zero dipendenze che dialoga con Proxmox VE e il QEMU Guest Agent:

  1. Avvio della Live: monta la ISO appena sfornata da Furnace in una VM di test dedicata (con profili BIOS + ext4, UEFI + ext4 e UEFI + btrfs).
  2. Installazione non presidiata: avvia la live ed esegue automaticamente l'installazione su disco tramite krill.
  3. Riavvio e Telemetria: scollega la ISO, riavvia la VM dal disco fisso appena installato ed estrae via QEMU Guest Agent il file /etc/fstab e il report diagnostico (fastfetch/neofetch), pubblicando la tabella dei risultati direttamente nel riepilogo di GitHub Actions ($GITHUB_STEP_SUMMARY).

Domanda a cui risponde Incubator: «La ISO prodotta da penguins-eggs si installa e si avvia correttamente da disco su filesystem ext4 e btrfs, sia in modalità BIOS che UEFI?»