Skip to Content
Building OsSoftware personalizat din depozite sursă

Software personalizat din depozite sursă

Rețetele OpenFactory pot referi un depozit Git ca intrare de pachet personalizat pe builderii de imagini acceptați. Este o cale sensibilă la lanțul de aprovizionare: depozitul, revizia rezolvată, instrucțiunile de împachetare, dependențele de build și pachetul produs necesită revizuire.

Suportul depinde de țintă. Buildurile de pachet sursă sunt respinse pe unii builderi, inclusiv pe căile actuale Raspberry Pi și Proxmox. Confirmați disponibilitatea în rețeta normalizată și planul de build înainte să promiteți că se va produce un pachet.

Forma rețetei

Intrările de pachet personalizat stau sub os.custom_packages:

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

Schema acceptă un nume de ramură, nu un câmp commit imutabil. Pentru o lansare controlată, înregistrați commitul exact rezolvat de build și includeți acel commit în provenance păstrat. O ramură în mișcare singură nu este intrare reproductibilă.

Pregătiți depozitul

Calea actuală de pachet așteaptă metadate native de împachetare potrivite țintei. Exemple uzuale sunt directorul Debian debian/ sau un spec RPM. Comportamentul exact al builderului și versiunile de țintă acceptate se pot schimba, deci validați un pachet minimal în mediul implementat în loc să vă bazați pe un tabel static de compatibilitate.

Pentru împachetare Debian, revizuiți cel puțin:

  • debian/control pentru identitatea source/binary și dependențe;
  • debian/changelog pentru versiunea pachetului;
  • debian/rules și alte scripturi maintainer executabile;
  • manifeste de instalare și unități systemd; și
  • licențiere și material terț împachetat.

Pentru împachetare RPM, revizuiți sursele din spec, cerințele de build, scriptleturile, lista de fișiere și metadatele de licență.

Nu presupuneți niciodată că proprietatea depozitului face scripturile de build sigure. Buildurile de pachet execută sursă și logică de împachetare neîncredere în interiorul limitei de izolare a infrastructurii de build.

Alte controale de pachet

Pachete native

Folosiți os.packages pentru pachete deja furnizate de distribuția aleasă sau un depozit configurat explicit:

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

Suprascrieri de pachet

os.package_overrides poate declara intenția add, remove sau replace:

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

O suprascriere nu dovedește că rezolvarea dependențelor a respectat-o. Verificați inventarul final de pachete și afirmațiile absence/presence.

Depozite suplimentare

os.extra_repos este intrare avansată. Nu adăugați un depozit HTTP nesemnat ca în exemplele vechi. O integrare aprobată de depozit necesită transport HTTPS, cheie de semnare fixată, aplicare a semnăturii, metadate release potrivite managerului de pachete și proprietate documentată plus politică de actualizare. Dacă builderul actual nu poate reprezenta aceste controale de încredere, nu folosiți depozitul.

Dovezi de acceptare

Pentru fiecare pachet personalizat, păstrați:

  • URL depozit și commit rezolvat;
  • revizuirea sursei și a licenței declarate;
  • mediul de build și instantaneul dependențelor;
  • jurnale de build și numele/versiunea/arhitectura pachetului rezultat;
  • digest pachet și dovezi de semnătură depozit, unde se aplică;
  • inventar final al imaginii cu pachetul instalat;
  • smoke teste de serviciu sau executabil; și
  • comportament la eliminare și upgrade.

O etapă reușită de pachet sursă nu ajunge. Buildul imaginii poate eșua ulterior să consume pachetul, iar un pachet instalat poate rămâne neutilizabil.

Depanare

  • Metadate de împachetare respinse: validați pachetul nativ local cu aceeași versiune de release a distribuției și aceeași arhitectură.
  • Lipsește dependența de build: folosiți dependențe din depozite aprobate pentru acea țintă; nu descărcați în tăcere binare arbitrare într-un script maintainer.
  • Pachet absent din imagine: comparați numele pachetului binar produs cu cererea normalizată de instalare și inventarul final.
  • Versiunea nu s-a schimbat: actualizați metadatele native de versiune și confirmați că noul commit sursă a fost rezolvat.
  • Serviciul a eșuat: inspectați unitatea, dependențele runtime, permisiunile și jurnalele oaspetelui; adăugați o afirmație la nivel de comportament înainte de rebuild.
Imagini de bazăImagini desktop