Compila una wheel de Python fuera de la red y publícala dentro

Ya tienes un trabajo de compilación que produce una wheel y un repositorio privado que debería recibirla. El error es dejar que un segundo trabajo recompile desde una rama y llamar al resultado la misma versión. Mueve el archivo que se probó, nómbralo por el resumen y mantén la credencial de subida dentro. El recorrido de abajo sigue un artefacto desde un ejecutor de CI público hasta un publicador interno.

Compila donde ya vive el código fuente

Ejecuta la compilación en el trabajo que ya tiene el código fuente, las herramientas y la batería de pruebas. Nada del repositorio privado exige que ese trabajo llegue a él. Instala el frontend de compilación en el entorno que el proyecto ya usa y luego produce ambos formatos de distribución si el proyecto entrega los dos.

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

Mantén el directorio de salida pequeño y desechable. Lo único que vale la pena trasladar son los archivos que publicará el siguiente trabajo, más sus hashes. Todo lo demás, incluidos los entornos virtuales y las cachés, se puede reconstruir a partir de la revisión registrada del código fuente. Un artefacto magro también es más fácil de revisar, porque cada archivo que contiene es un archivo que alguien puede inspeccionar.

Registra qué los produjo: el nombre del paquete y la versión a partir de los nombres de archivo, la revisión del código fuente y la ejecución del flujo de trabajo que los creó. Una cadena de versión por sí sola no identifica un archivo, porque la misma versión se puede compilar dos veces desde commits distintos. Escribe la revisión junto a los nombres de archivo en la descripción del artefacto y trata ese registro como parte de la entrega.

Mueve bytes, no instrucciones para recompilar

Una segunda compilación es un segundo producto. Las marcas de tiempo, las dependencias empaquetadas y las versiones de las herramientas pueden cambiar los bytes, así que una recompilación necesita sus propias pruebas y su propia revisión. Promueve en su lugar los archivos ya revisados.

Sube los archivos de distribución al almacén de artefactos que ofrece tu plataforma de CI y dale al trabajo interno una referencia a ese artefacto concreto, no a un nombre de rama.

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

Si tu plataforma admite procedencia firmada, pídele que atestigüe el artefacto y que después verifique el repositorio, el flujo de trabajo y la revisión del código fuente esperados. La documentación de atestaciones de GitHub describe afirmaciones de esa forma. Una firma válida es una prueba de origen, no un escaneo de vulnerabilidades ni una decisión de autorización.

Verifica dentro antes de subir

El trabajo interno empieza comprobando que el archivo que recibió es el archivo que se aprobó. Compara los resúmenes con el registro del trabajo de compilación, no con un valor recalculado a partir de lo que haya llegado.

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

Luego lee los metadatos. El nombre del paquete, la versión y las dependencias declaradas deberían coincidir con la revisión que aprobaste. Una wheel cuyo nombre parece correcto pero cuyos anclajes de dependencias han cambiado es otro paquete con la misma etiqueta. Si los metadatos se han movido, trata el artefacto como no aprobado y averigua qué compilación lo produjo.

Si los resúmenes no coinciden, detente. No subas y no repares el archivo recompilándolo en el sitio; eso borra la evidencia de que algo cambió en tránsito. Una discrepancia significa que el almacén de artefactos, el paso de descarga o el registro están mal, y cada uno de ellos merece una explicación antes de que se publique una versión.

Gestiona la respuesta de versión duplicada

Los repositorios privados suelen negarse a sobrescribir una versión existente, y esa negativa es una característica. Cuando una subida falla porque la versión existe, inspecciona el registro del repositorio para esa versión y compara los archivos que contiene con los resúmenes que pretendías publicar.

Una versión existente puede significar que una subida anterior tuvo éxito y la respuesta se perdió, o que alguien publicó contenido distinto bajo el mismo número.

No borres la versión ni inventes un número nuevo para sortear el error. Decide con el propietario de la versión si el contenido almacenado es aceptable y luego registra el resultado. Si el contenido difiere, tienes un problema de versionado, no un problema de pipeline.

Mantén la credencial de subida en un solo lado

Solo el publicador interno necesita credenciales del repositorio, y solo durante la subida. Limita el token al repositorio de destino y a las operaciones de subida, guárdalo en el almacén de secretos del sistema interno y déjalo completamente fuera del trabajo de compilación. Si el trabajo de compilación puede publicar, entonces cualquiera que pueda cambiar la compilación puede publicar.

Restringe también qué flujos de trabajo internos pueden iniciar el publicador. Un disparador manual con una aprobación obligatoria es un valor predeterminado razonable para las versiones; un push a cualquier rama no lo es.

La versión terminada debería dejar tres cosas detrás: los archivos de distribución, sus resúmenes junto con la revisión del código fuente y un registro del repositorio que muestre la misma versión.