Skip to Content
Building OsSoftware personalizzato da repository sorgente

Software personalizzato da repository sorgente

Le ricette OpenFactory possono referenziare un repository Git come input pacchetto personalizzato su builder immagine supportati. È un percorso sensibile alla supply chain: repository, revisione risolta, istruzioni di packaging, dipendenze di build e pacchetto prodotto richiedono tutti revisione.

Il supporto è specifico per target. Le build source-package sono rifiutate per alcuni builder, inclusi i percorsi Raspberry Pi e Proxmox attuali. Conferma disponibilità nella ricetta normalizzata e nel piano build prima di promettere che un pacchetto sarà prodotto.

Forma ricetta

Le voci pacchetto personalizzato stanno sotto os.custom_packages:

{
  "os": {
    "custom_packages": [
      {
        "name": "my-agent",
        "git_url": "https://github.com/example/my-agent.git",
        "branch": "release-1.x"
      }
    ]
  }
}

Lo schema accetta un nome branch, non un campo commit immutabile. Per una release controllata, registra il commit esatto risolto dalla build e rendilo parte della provenienza conservata. Un branch mobile da solo non è input riproducibile.

Prepara il repository

Il percorso pacchetto attuale si aspetta metadati di packaging nativi appropriati al target. Esempi comuni sono una directory Debian debian/ o uno spec RPM. Il comportamento esatto del builder e le versioni target supportate possono cambiare, quindi valida un pacchetto minimo nell’ambiente deployato invece di affidarti a una tabella di compatibilità statica.

Per packaging Debian, rivedi almeno:

  • debian/control per identità sorgente/binario e dipendenze;
  • debian/changelog per la versione pacchetto;
  • debian/rules e altri script maintainer eseguibili;
  • manifest di installazione e unit systemd; e
  • licenza e materiale third-party incluso.

Per packaging RPM, rivedi sorgenti, build requirements, scriptlet, file list e metadati licenza dello spec.

Non assumere mai che la proprietà del repository renda sicuri i suoi script di build. Le build pacchetto eseguono logica sorgente e packaging non fidata dentro il confine di isolamento dell’infrastruttura di build.

Altri controlli pacchetto

Pacchetti nativi

Usa os.packages per pacchetti già forniti dalla distribuzione selezionata o da un repository configurato esplicitamente:

{
  "os": {
    "packages": ["curl", "jq"]
  }
}

Override pacchetto

os.package_overrides può dichiarare intento add, remove o replace:

{
  "os": {
    "package_overrides": [
      {"name": "nano", "action": "replace", "replacement": "neovim"},
      {"name": "telnet", "action": "remove"}
    ]
  }
}

Un override non prova che la risoluzione dipendenze l’abbia rispettato. Verifica inventario pacchetto finale e asserzioni presenza/assenza.

Repository aggiuntivi

os.extra_repos è un input avanzato. Non aggiungere un repository HTTP non firmato come negli esempi più vecchi. Un’integrazione repository approvata richiede trasporto HTTPS, chiave di firma pin, enforcement firma, metadati release appropriati al package manager e policy di ownership e aggiornamento documentata. Se quei controlli di fiducia non possono essere rappresentati dal builder corrente, non usare il repository.

Evidenza di accettazione

Per ogni pacchetto personalizzato, conserva:

  • URL repository e commit risolto;
  • revisione sorgente e licenza dichiarata;
  • snapshot ambiente build e dipendenze;
  • log build e nome/versione/architettura pacchetto risultante;
  • digest pacchetto ed evidenza firma repository dove applicabile;
  • inventario immagine finale che mostra il pacchetto installato;
  • smoke test servizio o eseguibile; e
  • comportamento rimozione e upgrade.

Uno stage source-package riuscito non basta. La build immagine può fallire dopo nel consumare il pacchetto, e un pacchetto installato può restare inutilizzabile.

Risoluzione problemi

  • Metadati packaging rifiutati: valida il pacchetto nativo localmente con la stessa release distribuzione e architettura.
  • Dipendenza build mancante: usa dipendenze disponibili da repository approvati per quel target; non scaricare silenziosamente binari arbitrari in uno script maintainer.
  • Pacchetto assente dall’immagine: confronta il nome pacchetto binario prodotto con la richiesta install normalizzata e l’inventario finale.
  • Versione non cambiata: aggiorna metadati versione nativi e conferma che il nuovo commit sorgente sia stato risolto.
  • Servizio fallito: ispeziona unit, dipendenze runtime, permessi e log guest; aggiungi un’asserzione a livello comportamento prima di rebuildare.
Immagini baseImmagini desktop