Compila un wheel de Python fóra da rede e publícao dentro

Xa tes un traballo de compilación que produce un wheel e un repositorio privado que debería recibilo. O erro é deixar que un segundo traballo recompile desde unha rama e chamar ao resultado a mesma versión. Move o ficheiro que se probou, nómao polo resumo e mantén a credencial de subida dentro. O percorrido de abaixo segue un artefacto desde un executador de CI público ata un publicador interno.

Compila onde xa vive o código fonte

Executa a compilación no traballo que xa ten o código fonte, as ferramentas e a batería de probas. Nada do repositorio privado esixe que ese traballo chegue a el. Instala o frontend de compilación na contorna que o proxecto xa usa e despois produce ambos os formatos de distribución se o proxecto entrega os dous.

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

Mantén o directorio de saída pequeno e dun só uso. O único que paga a pena trasladar son os ficheiros que publicará o seguinte traballo, máis os seus hashes. Todo o demais, incluídos as contornas virtuais e as cachés, pódese reconstruír a partir da revisión rexistrada do código fonte. Un artefacto magro tamén é máis fácil de revisar, porque cada ficheiro que contén é un ficheiro que alguén pode inspeccionar.

Rexistra que os produciu: o nome do paquete e a versión a partir dos nomes de ficheiro, a revisión do código fonte e a execución do fluxo de traballo que os creou. Unha cadea de versión por si soa non identifica un ficheiro, porque a mesma versión se pode compilar dúas veces desde commits distintos. Escribe a revisión xunto aos nomes de ficheiro na descrición do artefacto e trata ese rexistro como parte da entrega.

Move bytes, non instrucións para recompilar

Unha segunda compilación é un segundo produto. As marcas de tempo, as dependencias empaquetadas e as versións das ferramentas poden cambiar os bytes, así que unha recompilación precisa as súas propias probas e a súa propia revisión. Promove no seu lugar os ficheiros xa revisados.

Sube os ficheiros de distribución ao almacén de artefactos que ofrece a túa plataforma de CI e dálle ao traballo interno unha referencia a ese artefacto concreto, non a un nome de rama.

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

Se a túa plataforma admite procedencia asinada, pídelle que ateste o artefacto e que despois verifique o repositorio, o fluxo de traballo e a revisión do código fonte esperados. A documentación de atestacións de GitHub describe afirmacións desa forma. Unha sinatura válida é unha proba de orixe, non un escaneo de vulnerabilidades nin unha decisión de autorización.

Verifica dentro antes de subir

O traballo interno comeza comprobando que o ficheiro que recibiu é o ficheiro que se aprobou. Compara os resumos co rexistro do traballo de compilación, non cun valor recalculado a partir do que chegase.

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

Despois le os metadatos. O nome do paquete, a versión e as dependencias declaradas deberían coincidir coa revisión que aprobaches. Un wheel cuxo nome parece correcto pero cuxos pins de dependencias cambiaron é outro paquete coa mesma etiqueta. Se os metadatos se moveron, trata o artefacto como non aprobado e descobre que compilación o produciu.

Se os resumos non coinciden, detente. Non subas e non repares o ficheiro recompilándoo no sitio; iso borra a evidencia de que algo cambiou en tránsito. Unha discrepancia significa que o almacén de artefactos, o paso de descarga ou o rexistro están mal, e cada un deles merece unha explicación antes de que se publique unha versión.

Xestiona a resposta de versión duplicada

Os repositorios privados adoitan negarse a sobrescribir unha versión existente, e esa negativa é unha característica. Cando unha subida falla porque a versión existe, inspecciona o rexistro do repositorio para esa versión e compara os ficheiros que contén cos resumos que pretendías publicar.

Unha versión existente pode significar que unha subida anterior tivo éxito e a resposta se perdeu, ou que alguén publicou contido distinto baixo o mesmo número.

Non borres a versión nin inventes un número novo para sortear o erro. Decide co propietario da versión se o contido almacenado é aceptable e despois rexistra o resultado. Se o contido difire, tes un problema de versionado, non un problema de pipeline.

Mantén a credencial de subida nun só lado

Só o publicador interno necesita credenciais do repositorio, e só durante a subida. Limita o token ao repositorio de destino e ás operacións de subida, gárdao no almacén de segredos do sistema interno e déixao completamente fóra do traballo de compilación. Se o traballo de compilación pode publicar, entón calquera que poida cambiar a compilación pode publicar.

Restrinxe tamén que fluxos de traballo internos poden iniciar o publicador. Un disparador manual cunha aprobación obrigatoria é un valor por defecto razoable para as versións; un push a calquera rama non o é.

A versión rematada debería deixar tres cousas detrás: os ficheiros de distribución, os seus resumos xunto coa revisión do código fonte e un rexistro do repositorio que mostre a mesma versión.