Construisez un wheel Python hors du réseau, publiez-le à l'intérieur

Vous avez déjà une tâche de build qui produit un wheel, et un dépôt privé qui doit le recevoir. L'erreur est de laisser une seconde tâche reconstruire depuis une branche et d'appeler le résultat la même version. Déplacez le fichier qui a été testé, nommez-le d'après l'empreinte, et gardez l'identifiant de publication à l'intérieur. La procédure ci-dessous suit un artefact d'un runner de CI public jusqu'à un éditeur interne.

Construisez là où le code source se trouve déjà

Exécutez le build dans la tâche qui possède déjà le code source, la chaîne d'outils et la suite de tests. Rien dans un dépôt privé n'exige que cette tâche l'atteigne. Installez le frontend de build dans l'environnement que le projet utilise déjà, puis produisez les deux formats de distribution si le projet livre les deux.

python -m build --sdist --wheel --outdir dist
python -m twine check dist/*

Gardez le répertoire de sortie petit et jetable. Les seules choses qui valent la peine d'être transmises sont les fichiers que la tâche suivante publiera, plus leurs hachages. Tout le reste, y compris les environnements virtuels et les caches, peut être reconstruit à partir de la révision enregistrée du code source. Un artefact léger est aussi plus facile à relire, car chaque fichier qu'il contient est un fichier que quelqu'un peut inspecter.

Enregistrez ce qui les a produits : le nom du paquet et la version à partir des noms de fichiers, la révision du code source, et l'exécution du flux de travail qui les a créés. Une chaîne de version seule n'identifie pas un fichier, car la même version peut être construite deux fois depuis des commits différents. Écrivez la révision à côté des noms de fichiers dans la description de l'artefact, et traitez cet enregistrement comme faisant partie de la remise.

Déplacez des octets, pas des instructions de reconstruction

Une seconde construction est un second produit. Les horodatages, les dépendances embarquées et les versions d'outils peuvent tous modifier les octets, donc une reconstruction a besoin de ses propres preuves de test et de sa propre revue. Promouvez plutôt les fichiers déjà relus.

Téléversez les fichiers de distribution dans le magasin d'artefacts fourni par votre plateforme de CI, et donnez à la tâche interne une référence à cet artefact précis plutôt qu'à un nom de branche.

sha256sum dist/*.whl dist/*.tar.gz
# keep the digests beside the run id in the artifact description

Si votre plateforme prend en charge la provenance signée, demandez-lui d'attester l'artefact et de vérifier ensuite le dépôt, le flux de travail et la révision du code source attendus. La documentation d'attestation de GitHub décrit des affirmations de cette forme. Une signature valide est une preuve d'origine, ce n'est ni un scan de vulnérabilités ni une décision d'autorisation.

Vérifiez à l'intérieur avant de téléverser

La tâche interne commence par vérifier que le fichier reçu est bien le fichier approuvé. Comparez les empreintes à l'enregistrement de la tâche de build, et non à une valeur recalculée à partir de ce qui est arrivé.

sha256sum -c digests.txt
python -m twine check dist/*

Lisez ensuite les métadonnées. Le nom du paquet, la version et les dépendances déclarées doivent correspondre à la revue que vous avez approuvée. Un wheel dont le nom semble correct mais dont les épinglages de dépendances ont changé est un autre paquet portant la même étiquette. Si les métadonnées ont bougé, traitez l'artefact comme non approuvé et déterminez quel build l'a produit.

Si les empreintes ne correspondent pas, arrêtez-vous. Ne téléversez pas, et ne réparez pas le fichier en le reconstruisant sur place ; cela efface la preuve que quelque chose a changé en transit. Une divergence signifie que le magasin d'artefacts, l'étape de téléchargement ou l'enregistrement est erroné, et chacun mérite une explication avant qu'une version soit publiée.

Traitez la réponse de version dupliquée

Les dépôts privés refusent généralement d'écraser une version existante, et ce refus est une fonctionnalité. Quand un téléversement échoue parce que la version existe, inspectez l'enregistrement du dépôt pour cette version et comparez les fichiers qu'il contient aux empreintes que vous comptiez publier.

Une version existante peut signifier qu'un téléversement antérieur a réussi et que la réponse a été perdue, ou que quelqu'un a publié un contenu différent sous le même numéro.

Ne supprimez pas la version et n'inventez pas un nouveau numéro pour contourner l'erreur. Décidez avec le responsable de la version si le contenu stocké est acceptable, puis consignez le résultat. Si le contenu diffère, vous avez un problème de versionnement, pas un problème de pipeline.

Gardez l'identifiant de téléversement d'un seul côté

Seul l'éditeur interne a besoin d'identifiants de dépôt, et seulement le temps du téléversement. Limitez le jeton au dépôt cible et aux opérations de téléversement, gardez-le dans le coffre de secrets du système interne, et laissez-le entièrement hors de la tâche de build. Si la tâche de build peut publier, alors quiconque peut modifier le build peut publier.

Restreignez aussi quels flux de travail internes peuvent démarrer l'éditeur. Un déclencheur manuel avec une approbation obligatoire est une valeur par défaut raisonnable pour les versions ; un push vers n'importe quelle branche ne l'est pas.

La version terminée devrait laisser trois choses derrière elle : les fichiers de distribution, leurs empreintes avec la révision du code source, et un enregistrement de dépôt montrant la même version.