Skip to Content
Building OsLogiciel personnalisé depuis des dépôts source

Logiciel personnalisé depuis des dépôts source

Les recettes OpenFactory peuvent référencer un dépôt Git comme entrée de paquet personnalisé sur les builders d’image supportés. C’est un chemin sensible à la chaîne d’approvisionnement : le dépôt, la révision résolue, les instructions d’empaquetage, les dépendances de build et le paquet produit exigent tous une relecture.

Le support dépend de la cible. Les builds de paquets source sont rejetés pour certains builders, dont les chemins Raspberry Pi et Proxmox actuels. Confirmez la disponibilité dans la recette normalisée et le plan de build avant de promettre qu’un paquet sera produit.

Forme de recette

Les entrées de paquets personnalisés vivent sous os.custom_packages :

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

Le schéma accepte un nom de branche, pas un champ de commit immuable. Pour une version contrôlée, enregistrez le commit exact résolu par le build et faites-en partie de la provenance conservée. Une branche mobile seule n’est pas une entrée reproductible.

Préparer le dépôt

Le chemin de paquet actuel attend des métadonnées d’empaquetage natives adaptées à la cible. Les exemples courants sont un répertoire Debian debian/ ou un spec RPM. Le comportement exact du builder et les versions cibles supportées peuvent changer ; validez donc un paquet minimal dans l’environnement déployé plutôt que de vous fier à un tableau de compatibilité statique.

Pour l’empaquetage Debian, relisez au minimum :

  • debian/control pour identité source/binaire et dépendances ;
  • debian/changelog pour la version du paquet ;
  • debian/rules et autres scripts mainteneur exécutables ;
  • manifestes d’installation et unités systemd ; et
  • licence et contenu tiers inclus.

Pour l’empaquetage RPM, relisez les sources du spec, les prérequis de build, les scriptlets, la liste de fichiers et les métadonnées de licence.

Ne supposez jamais que la propriété du dépôt rend ses scripts de build sûrs. Les builds de paquets exécutent une logique source et d’empaquetage non fiable dans la frontière d’isolation de l’infrastructure de build.

Autres contrôles de paquets

Paquets natifs

Utilisez os.packages pour les paquets déjà fournis par la distribution sélectionnée ou un dépôt explicitement configuré :

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

Remplacements de paquets

os.package_overrides peut déclarer une intention add, remove ou replace :

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

Un override n’est pas une preuve que la résolution de dépendances l’a honoré. Vérifiez l’inventaire final des paquets et les assertions de présence/absence.

Dépôts supplémentaires

os.extra_repos est une entrée avancée. N’ajoutez pas un dépôt HTTP non signé comme dans d’anciens exemples. Une intégration de dépôt approuvée nécessite transport HTTPS, clé de signature épinglée, application de signature, métadonnées de version adaptées au gestionnaire de paquets, et politique documentée de propriété et de mise à jour. Si ces contrôles de confiance ne peuvent pas être représentés par le builder courant, n’utilisez pas le dépôt.

Preuves d’acceptation

Pour chaque paquet personnalisé, conservez :

  • URL du dépôt et commit résolu ;
  • relecture source et licence déclarée ;
  • instantané d’environnement de build et de dépendances ;
  • journaux de build et nom/version/architecture du paquet résultant ;
  • digest du paquet et preuve de signature de dépôt le cas échéant ;
  • inventaire final de l’image montrant le paquet installé ;
  • tests fumée de service ou d’exécutable ; et
  • comportement de suppression et de mise à niveau.

Une étape source-package réussie ne suffit pas. Le build d’image peut échouer ensuite à consommer le paquet, et un paquet installé peut rester inutilisable.

Dépannage

  • Métadonnées d’empaquetage rejetées : validez le paquet natif localement avec la même version de distribution et architecture.
  • Dépendance de build manquante : utilisez des dépendances disponibles depuis des dépôts approuvés pour cette cible ; ne récupérez pas silencieusement des binaires arbitraires dans un script mainteneur.
  • Paquet absent de l’image : comparez le nom du paquet binaire produit avec la demande d’installation normalisée et l’inventaire final.
  • Version inchangée : mettez à jour les métadonnées de version natives et confirmez que le nouveau commit source a été résolu.
  • Service en échec : inspectez son unité, dépendances d’exécution, permissions et journaux invité ; ajoutez une assertion au niveau comportement avant de rebuilder.
Images de baseImages bureau