Skip to Content
Building OsAnpassad programvara från källkodsrepositorier

Anpassad programvara från källkodsrepositorier

OpenFactory-recept kan referera till ett Git-repository som custom package-input på image-builders som stöds. Det här är en supply-chain-känslig väg: repositoryt, den lösta revisionen, packaging-instruktioner, build-beroenden och det producerade paketet behöver alla granskas.

Stödet beror på målet. Source package-builds avvisas för vissa builders, inklusive nuvarande Raspberry Pi- och Proxmox-vägar. Bekräfta tillgänglighet i det normaliserade receptet och build-planen innan du lovar att ett paket ska produceras.

Receptform

Custom package-poster ligger under os.custom_packages:

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

Schemat accepterar ett branch-namn, inte ett oföränderligt commit-fält. För en kontrollerad release: registrera exakt den commit som builden löser och gör den commiten till en del av bevarad provenance. En rörlig branch ensam är inte reproducerbar input.

Förbered repositoryt

Den nuvarande package-vägen förväntar sig native packaging-metadata som passar målet. Vanliga exempel är en Debian-katalog debian/ eller en RPM-spec. Exakt builder-beteende och stödda målversioner kan ändras, så validera ett minimalt paket i den utrullade miljön i stället för att lita på en statisk kompatibilitetstabell.

För Debian-packaging, granska minst:

  • debian/control för source/binary-identitet och beroenden;
  • debian/changelog för paketversionen;
  • debian/rules och andra körbara maintainer-skript;
  • installationsmanifest och systemd-enheter; och
  • licensiering och inbundet material från tredje part.

För RPM-packaging, granska spec:ens källor, build-krav, scriptlets, fillista och licensmetadata.

Anta aldrig att repository-ägarskap gör dess build-skript säkra. Package-builds kör opålitlig källkod och packaging-logik innanför build-infrastrukturens isoleringsgräns.

Övriga package-kontroller

Native packages

Använd os.packages för paket som redan levereras av vald distribution eller ett uttryckligen konfigurerat repository:

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

Package overrides

os.package_overrides kan deklarera avsikt add, remove eller replace:

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

En override bevisar inte att dependency resolution följde den. Verifiera slutlig paketinventering och absence/presence-assertions.

Ytterligare repositories

os.extra_repos är en avancerad input. Lägg inte till ett osignerat HTTP-repository som i äldre exempel. En godkänd repository-integration kräver HTTPS-transport, en fastnålad signing key, signaturkontroll, release-metadata som passar package manager, samt dokumenterat ägarskap och uppdateringspolicy. Om de trust controls inte kan representeras av nuvarande builder, använd inte repositoryt.

Acceptansbevis

För varje custom package, behåll:

  • repository-URL och löst commit;
  • granskning av källkod och deklarerad licens;
  • build-miljö och dependency-snapshot;
  • build-loggar och resulterande paketnamn/version/arkitektur;
  • package digest och repository-signature-bevis där det gäller;
  • slutlig image-inventering som visar paketet installerat;
  • service- eller executable-smoke-tester; och
  • beteende vid borttagning och uppgradering.

En lyckad source package-fas räcker inte. Image-builden kan senare misslyckas med att konsumera paketet, och ett installerat paket kan fortfarande vara oanvändbart.

Felsökning

  • Packaging-metadata avvisad: validera det native paketet lokalt med samma distributionsrelease och arkitektur.
  • Build-beroende saknas: använd beroenden från godkända repositories för det målet; hämta inte godtyckliga binärer tyst i ett maintainer-skript.
  • Paket saknas i imagen: jämför det producerade binära paketnamnet med normaliserad installationsbegäran och slutlig inventering.
  • Versionen ändrades inte: uppdatera native versionsmetadata och bekräfta att den nya source-committen löstes.
  • Tjänsten misslyckades: inspektera enheten, runtime-beroenden, behörigheter och gästloggar; lägg till en beteendeassertion före rebuild.
BasavbilderDesktopavbilder