Construeix una wheel de Python fora de la xarxa i publica-la a dins

Ja tens una tasca de compilació que produeix una wheel i un repositori privat que l'ha de rebre. L'error és deixar que una segona tasca torni a compilar des d'una branca i anomenar el resultat la mateixa versió. Mou el fitxer que s'ha provat, anomena'l pel resum i mantén la credencial de pujada a dins. El recorregut de sota segueix un artefacte des d'un executor de CI públic fins a un publicador intern.

Compila on ja viu el codi font

Executa la compilació a la tasca que ja té el codi font, les eines i la bateria de proves. Res del repositori privat no exigeix que aquella tasca hi arribi. Instal·la el frontal de compilació a l'entorn que el projecte ja fa servir i després produeix els dos formats de distribució si el projecte els publica tots dos.

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

Mantén el directori de sortida petit i d'un sol ús. L'únic que val la pena traslladar són els fitxers que publicarà la tasca següent, més els seus hashes. Tota la resta, inclosos els entorns virtuals i les memòries cau, es pot reconstruir a partir de la revisió registrada del codi font. Un artefacte magre també és més fàcil de revisar, perquè cada fitxer que conté és un fitxer que algú pot inspeccionar.

Registra què els ha produït: el nom del paquet i la versió a partir dels noms dels fitxers, la revisió del codi font i l'execució del flux de treball que els ha creat. Una cadena de versió sola no identifica un fitxer, perquè la mateixa versió es pot compilar dues vegades des de commits diferents. Escriu la revisió al costat dels noms dels fitxers a la descripció de l'artefacte i tracta aquest registre com a part del lliurament.

Mou bytes, no instruccions per tornar a compilar

Una segona compilació és un segon producte. Les marques de temps, les dependències empaquetades i les versions de les eines poden canviar els bytes, així que una recompilació necessita les seves pròpies proves i la seva pròpia revisió. Promou en lloc d'això els fitxers ja revisats.

Puja els fitxers de distribució al magatzem d'artefactes que ofereix la teva plataforma de CI i dona a la tasca interna una referència a aquell artefacte concret, no a un nom de branca.

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

Si la teva plataforma admet procedència signada, demana-li que attestigui l'artefacte i que després verifiqui el repositori, el flux de treball i la revisió del codi font esperats. La documentació d'atestacions de GitHub descriu afirmacions d'aquesta forma. Una signatura vàlida és una prova d'origen, no un escaneig de vulnerabilitats ni una decisió d'autorització.

Verifica a dins abans de pujar

La tasca interna comença comprovant que el fitxer que ha rebut és el fitxer que es va aprovar. Compara els resums amb el registre de la tasca de compilació, no amb un valor recalculat a partir del que hagi arribat.

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

Després llegeix les metadades. El nom del paquet, la versió i les dependències declarades haurien de coincidir amb la revisió que vas aprovar. Una wheel el nom de la qual sembla correcte però les fixacions de dependències de la qual han canviat és un altre paquet amb la mateixa etiqueta. Si les metadades s'han mogut, tracta l'artefacte com a no aprovat i esbrina quina compilació l'ha produït.

Si els resums no coincideixen, atura't. No pugis ni repareu el fitxer recompilant-lo al lloc; això esborra l'evidència que alguna cosa ha canviat en trànsit. Una discrepància vol dir que el magatzem d'artefactes, el pas de descàrrega o el registre són incorrectes, i cadascun d'ells mereix una explicació abans que es publiqui una versió.

Gestiona la resposta de versió duplicada

Els repositoris privats normalment es neguen a sobreescriure una versió existent, i aquesta negativa és una característica. Quan una pujada falla perquè la versió existeix, inspecciona el registre del repositori per a aquella versió i compara els fitxers que conté amb els resums que volies publicar.

Una versió existent pot significar que una pujada anterior va tenir èxit i la resposta es va perdre, o que algú va publicar contingut diferent sota el mateix número.

No esborris la versió ni inventis un número nou per saltar-te l'error. Decideix amb el propietari de la versió si el contingut desat és acceptable i després registra el resultat. Si el contingut difereix, tens un problema de versionat, no un problema de pipeline.

Mantén la credencial de pujada en un sol costat

Només el publicador intern necessita credencials del repositori, i només durant la pujada. Limita el testimoni al repositori de destinació i a les operacions de pujada, guarda'l al magatzem de secrets del sistema intern i deixa'l completament fora de la tasca de compilació. Si la tasca de compilació pot publicar, aleshores qualsevol que pugui canviar la compilació pot publicar.

Restringeix també quins fluxos de treball interns poden engegar el publicador. Un activador manual amb una aprovació obligatòria és un valor per defecte raonable per a les versions; un push a qualsevol branca no ho és.

La versió acabada hauria de deixar tres coses enrere: els fitxers de distribució, els seus resums amb la revisió del codi font i un registre del repositori que mostri la mateixa versió.