Paketbaurichtlinien für Ansible Collections

Ansible-Collections sind paketierte Einheiten von Ansible-Inhalten, darunter Module und andere Plugin-Typen. Die meisten Ansible-Plugins sind in Python oder PowerShell geschrieben.

Einige Collections sind auch im ansible-Collectionss-Paket der Ansible Community enthalten, das in Fedora paketiert wird. Alle Collections, unabhängig davon, ob sie im ansible-Paket enthalten sind oder nicht, können in Fedora paketiert werden.

ansible ist von ansible-core abhängig, welches die Kern-Engine und CLI-Programme (z. B. ansible, ansible-playbook) enthält. Das Paket ansible hat einen anderen Veröffentlichungszyklus als die einzelnen Collections und kann ältere Versionen der einzelnen Komponenten enthalten. ansible installiert Collections in einem separaten Namensraum und kann parallel zu den einzelnen Collections installiert werden. Die Ansible-Engine sucht zuerst im eigenständigen Collections-Verzeichnis nach Collections.

In Changes/Ansible5 finden Sie weitere Information über die Trennung zwischen ansible und ansible-core.

Collections-Pakete MÜSSEN einen Namen der Form ansible-collection-NAMENSRAUM-NAME tragen. Beispielsweise heißt das community.general-Collections-Paket ansible-collection-community-general.

Der Quellcode einer Collection MUSS aus dem jeweiligen GitForge-Repository oder einem anderen Versionsverwaltungssystem (SCM-Repository) der Collection heruntergeladen werden. Die in Ansible Galaxy veröffentlichten Tarballs enthalten zwar den gesamten Python-/PowerShell-Quellcode der Collection sowie einige Entwicklungsdateien, jedoch nicht die Baukonfigurationsdatei galaxy.yml und die Entwicklungsdateien (z.B. Unit-Tests), die der Autor gegebenenfalls entfernt haben könnte. Beachten Sie, dass die Collections-Richtlinien der Ansible Community vorschreiben, dass Collections in einem öffentlichen SCM-Repository gekennzeichnet werden müssen.

Collections-Pakete SOLLTEN %{ansible_collection_url NAMENSRAUM NAME} als URL: des Pakets verwenden. Dies verweist auf die Homepage der Collection auf Ansible Galaxy.

Zum Erstellen des Collections-Artefakts MÜSSEN Pakete %ansible_collection_build in %build verwenden. %ansible_collection_install MUSS in %install verwendet werden, um das Artefakt zu installieren.

Paketierer SOLLTEN %files -f %{ansible_collection_filelist} verwenden, um die Collection zu installieren. Die %{ansible_collection_filelist} wird von %ansible_collection_install befüllt.

Gemäß den allgemeinen Fedora-Paketbaurichtlinien SOLLTEN Collections-Pakete, sofern praktikabel, von Upstream-Entwicklern gelieferte Unit-Tests in %check ausführen. Integrationstests können in der RPM-Bauumgebung nicht ausgeführt werden. Um Unit-Tests auszuführen, MÜSSEN Collections ansible-packaging-tests als BuildRequire einbinden, wodurch die notwendigen Abhängigkeiten hereingezogen werden. Einige Collections haben weitere Testabhängigkeiten, die üblicherweise in tests/unit/requirements.txt angegeben sind. Diese müssen manuell hinzugefügt werden. Das Makro %ansible_test_unit MUSS zum Ausführen von Tests verwendet werden.

Standardmäßig werden Collections mit allen Dateien aus dem Wurzelverzeichnis des Repositorys ausgeliefert, sofern diese nicht manuell ausgeschlossen werden. Daher enthalten viele Collections Entwicklungsdateien, die von den Benutzern nicht benötigt werden.

Paketierer SOLLTEN diese Dateien ausschließen. Dies SOLLTE durch Patchen der galaxy.yml-Datei der Collection erfolgen, um diese Dateien zur build_ignore-Konfiguration hinzuzufügen. Diese Dateien SOLLTEN NICHT mit rm entfernt werden. Weitere Informationen zur Syntax der galaxy.yml-Datei finden Sie in der Ansible-Dokumentation.

Gängige Entwicklungsdateien umfassen:

Diese Dateien müssen häufig downstream-seitig entfernt werden, da es einige ungelöste Probleme beim Übertragen dieser Änderungen in die Upstream-Community-Collections gibt. Diese Probleme sind im Fedora-Kontext irrelevant.

Ansible-Plugins sind nicht ausführbar. Viele von ihnen enthalten jedoch aus Kompatibilitätsgründen #!/usr/bin/python-Shebangs. Diese Shebangs MÜSSEN aus folgenden Gründen entfernt werden:

%py3_shebang_fix darf NICHT verwendet werden, da dies die Kompatibilität zu bestimmten Ansible-Zielknoten beeinträchtigt. Auch das Problem mit nicht ausführbaren Dateien wird dadurch nicht behoben.

Shebangs können folgendermaßen entfernt werden:

Lizenzdateien und Dokumentation für Collections werden standardmäßig im Collections-Verzeichnis unter /usr/share/ansible installiert. Paketierer können die Lizenz- und Dokumentationsdateien in diesem Verzeichnis entweder mit %license und %doc kennzeichnen oder die korrekten Pfade in galaxy.yml zu build_ignore hinzufügen und sie in den Standardverzeichnissen installieren. Vermeiden Sie es, diese Dateien an beiden Orten zu duplizieren.

Beachten Sie, dass einige Collections mit Mehrfachlizenzierung die Lizenzen in einem Verzeichnis LICENSES speichern. Dieses gesamte Verzeichnis MUSS mit %license gekennzeichnet sein.

Die Regeln zu zulässigen Lizenzen und zur Bestimmung des Feldes License: finden Sie in der Legal-Dokumentation.

build_ignore.patch:

Hier folgt eine kurze Aufschlüsselung der genauen Funktion jedes einzelnen Makros in ansible-packaging.