Portón Fedora Rawhide

Las siguientes páginas documentan el mecanismo de control de acceso recientemente habilitado en Fedora Rawhide.

La intención de esta iniciativa es establecer la infraestructura necesaria para que los paquetes se puedan filtrar según los resultados de las pruebas antes de su inclusión en Fedora Rawhide. Esto reducirá la cantidad de dependencias rotas, paquetes que no se pueden instalar y compilaciones defectuosas, lo que, en última instancia, dará como resultado una versión más estable de Rawhide. Además, este marco también aliviará la carga de trabajo de los equipos de ingeniería de infraestructura y lanzamiento que se encargan de que las compilaciones sigan funcionando correctamente.

Razones para la restricción de acceso

El principio básico de esta propuesta es proporcionar un entorno en el que se puedan crear y probar paquetes sin afectar a otros paquetes.

Al analizar cómo se condicionan las actualizaciones de paquetes de Rawhide a los resultados de las pruebas, debemos considerar dos flujos de trabajo: actualizaciones de compilación única, en las que la compilación contenida está poco acoplada a otras compilaciones, y actualizaciones de compilación múltiple, en las que las compilaciones están estrechamente acopladas.

  • Para un única compilación, la solución más sencilla es proporcionar una etiqueta Koji dedicada en la que se compilen estos paquetes y donde esperen a que pasen sus pruebas antes de poder entrar en el buildroot.

  • Para multiple builds, la solución consiste en utilizar las «etiquetas laterales» de Koji. Estas etiquetas laterales son básicamente etiquetas creadas por el empaquetador y disponibles para que este realice su trabajo, en este caso, recompilar todos los paquetes deseados. La etiqueta lateral se puede enviar al sistema de pruebas como una unidad de cambio.

Para usar una analogía ya conocida, una única actualización de compilación es como enviar una confirmación a una lista de correo: espera allí a ser revisada y aprobada antes de ser fusionada con el repositorio principal. Las actualizaciones de múltiples compilaciones son más parecidas a las solicitudes de extracción: pueden contener una o más compilaciones que se revisan y prueban juntas como un solo cambio antes de ser fusionadas.

Rawhide es un lugar único en el ecosistema de Fedora: es el único donde se pueden realizar grandes cambios y recompilaciones. En las versiones estables de Fedora, las directrices de empaquetado desaconsejan la recompilación de conjuntos de paquetes grandes, por lo que la proporción de actualizaciones de una sola compilación frente a las de múltiples compilaciones en Bodhi (95 % frente a 5 %) no refleja la realidad del ecosistema de Rawhide.

El objetivo de Rawhide Gating es crear la infraestructura necesaria para controlar la distribución de paquetes en Rawhide. La idea es que los paquetes pasen por Bodhi, se sometan a pruebas y, si las superan, se integren en el repositorio de compilación de Rawhide, como ocurre actualmente. En el caso más sencillo, el flujo de trabajo del empaquetador no se verá afectado por esta propuesta; en situaciones más complejas, se requerirán ajustes en dicho flujo de trabajo. Sin embargo, estos ajustes son mínimos.

No se harán obligatorias las pruebas durante la introducción de este marco. Corresponde a la comunidad (y a FESCo) decidir si se requieren pruebas y, en caso afirmativo, qué reglas se deben aplicar a todos los paquetes.

Lecturas Adicionales

Want to help? Learn how to contribute to Fedora Docs ›