Actualizaciones de Múltiples Compilaciones

Estamos trabajando en este flujo de trabajo y actualizaremos esta página y enviaremos un anuncio cuando este preparada o disponible para pruebas. Este es un trabajo en marcha y nos gustaría tener sus comentarios sobre como trabajaría esto desde la perspectiva de la experiencia de usuario. Comuníquese con nosotros en #fedora-ci o póngase en contacto con cualquier miembro del equipo.

Puede encontrar algunas pistas sobre la dirección que estamos tomando en:

¿Qué son las Actualizaciones de Múltiples Compilaciones?

Las actualizaciones de múltiples compilaciones contienen múltiples compilaciones que están estrechamente vinculadas entre sí.

Para paquetes compilados que dependen de una determinada ABI (Interfaz Binaria de Aplicaciones) o soname, es fácil entender como están vinculadas estrechamente. Sin embargo, los programas no binarios también pueden tener dependencias tan fuertes.

Por ejemplo, los paquetes rpms/python-urllib3 y rpms/python-requests están fuertemente vinculados. Las actualizaciones para python-urllib3 necesitan tener a python-requests en consideración. En algún momento la actualización está bien, en algún momento necesita esperar una nueva versión de python-requests, en cuyo caso ambas construcciones necesitan ser probadas juntas como una unidad.

Los paquetes de este estilo son candidatos a un flujo de trabajo de actualización de múltiples compilaciones. Necesitan ser compilados y probados juntos.

¿Cómo funcionan las actualizaciones de Gating Multi-Builds?

Para controlar las actualizaciones que involucran múltiples compilaciones, debemos compilar y probar de forma aislada de otras compilaciones. Esto es, el sistema CI (Integración Continúa) puede tomar las compilaciones, probarlas, controlarlas o dejarlas pasar, sin tener en consideración ningún otro cambio (esto es, paquetes/construcciones).

El flujo de trabajo es el siguiente:

  • Primero necesita crear una etiqueta lateral a través de fedpkg request-side-tag. Esto creará una etiqueta lateral con un nombre como <base-tag>-side-<id>.

  • Usted puede construir todos los paquetes que desee en está etiqueta lateral usando: fedpkg build --target=<side-tag-name>.

  • Si necesita crear en cadena algunos paquetes y desea asegurarse de que el anterior está disponible en la etiqueta lateral buildroot, utilice:koji wait-repo <side-tag-name> --build=<build-nvr>.

  • Una vez que ha construido todos los paquetes en su etiqueta lateral, puede crear la actualización bodhi para esta etiqueta lateral usando:

  • la UI (Interfaz de Usuario) web bodhi, en el nuevo formulario de actualización use el botón Use Side Tag (Usar Etiqueta Lateral)

  • la CLI (Interfaz de Línea de Comando) bodhi bodhi updates new --from-tag

  • Bodhi creará entonces dos etiquetas laterales:

  • <your-side-tag>-signing-pending

  • <your-side-tag>-testing-pending

  • Las construcciones en su etiqueta lateral serán movidas hacia <your-side-tag>-signing-pending y la actualización será puesta en el estado de Pending (Pendiente).

  • Nuestro bus de mensajes notifica a RoboSignatory que sus compilaciones llegaron a esta etiqueta, las cogerá, las firmará y las moverá a la etiqueta <your-side-tag>-testing-pending.

  • Nuestro bus de mensaje notifica a Bodhi que sus compilaciones fueron firmadas y movidas a esta etiqueta, marcará las compilaciones como firmadas y una todas las compilaciones han sido firmadas, moverá la actualización al estado Testing (En Prueba).

  • Se ejecutarán las pruebas, sus resultados serán reportados a ResultsDB que anunciará estos resultados, haciendo que Greenwave consulte cada archivo gating.yaml para ver si todos los criterios requeridos para estas compilaciones se cumplen o no. Si los tienen, Greenwave enviará un mensaje al bus de mensajes anunciando su decisión.

  • Bodhi escuchará en el bus la decisión tomada por Greenwave sobre las actualizaciones. Al recibirlos enviará la actualización correspondiente a la etiqueta Koji final (esto es, la etiqueta estable) y marca la actualización como Stable.

En este punto, sus compilaciones han llegado a la etiqueta estable de Koji, por lo tanto, esta disponible en buildroot para que cualquiera pueda usarlo y confiar en él y la actualización correspondiente de Bodhi se ha marcado como estable.

enga en cuenta que el hecho de que la actualización sea stable no significa que podrá instalarla por medio de dnf/yum. Significa que la compilación está disponible en el buildroot de Rawhide. Será llevada al espejo una vez que la próxima composición Rawhide tenga éxito.

Si usted ha creado una etiqueta lateral y no tiene uso para ella (y no crea una actualización para ella), elimínela para que no consuma recursos en la infraestructura de compilación. Simplemente elimine las etiquetas laterales que ha creado usando fedpkg remove-side-tag y usted puede listar sus etiquetas laterales usando fedpkg list-side-tags --user=<username>.

Diagrama simplificado del flujo de trabajo de las actualizaciones de múltiples compilaciones

Simplified multi builds update

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