¿Cómo optar en Gating?

Hay dos pasos a seguir con el objetivo de optar a Rawhide Gating:

  • Añadir pruebas a su paquete.

  • Configurar la activación, para que su paquete esté controlado en esas pruebas.

Añada Pruebas a Su Paquete

Puede añadir pruebas siguiendo la documentación sobre como escribir pruebas.

La esencia es: Añadir una carpeta tests/ en el repositorio git de su paquete y colocar un archivo llamado tests.yml en ellat. Este archivo debería ser un Ansible playbook con todos los pasos requeridos para probar su paquete.

Usted necesita “etiquetar” el manual con alguno o todos de los siguientes indicadores de modo que se pueda llamar a las pruebas en diferentes entornos: classic, container, atomic.

Una vez que usted ha añadido un archivo tests/tests.yml, para cada actualización que se creen seguidamente para este paquete, se ejecutarán las pruebas y se m ostrarán el la página de actualización baja la pestaña de resultado de pruebas.

Para que estas pruebas tengan efecto, usted necesita configurar el sistema para que las controle.

Configurar Gating

Para configurar el sistema para controlar su paquete en las pruebas, usted necesita añadir un archivo llamado gating.yaml al repositorio git del paquete(s) que desea controlar.

Un sencillo ejemplo para gating.yaml se vería como esto:

--- !Policy
product_versions:
  - fedora-*
decision_context: bodhi_update_push_testing
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
--- !Policy
product_versions:
  - fedora-*
decision_context: bodhi_update_push_stable
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}

Básicamente, contiene dos políticas, una para enviar una compilación a prueba y otra para enviar una compilación a estable y, para ambas situaciones, solicita que se pase la prueba org.centos.prod.ci.pipeline.allpackages-build.complete.

Para gating rawhide mismo, usted necesita decision_context: bodhi_update_push_stable, mientras que para las ramas estable, necesitará ambas.

Si lo único que le interesa es controlas sus pruebas a nivel paquete, puede usar este ejemplo tal como está.

Si usted está interesado en algunas de las verificaciones Taskotron, como dist.python-versions o dist.python-versions.py3_support, usted podría modificar el archivo para que se vea así:

--- !Policy
product_versions:
  - fedora-*
decision_context: bodhi_update_push_testing
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
  - !PassingTestCaseRule {test_case_name: dist.python-versions}
  - !PassingTestCaseRule {test_case_name: dist.python-versions.py3_support}
--- !Policy
product_versions:
  - fedora-*
decision_context: bodhi_update_push_stable
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
  - !PassingTestCaseRule {test_case_name: dist.python-versions}
  - !PassingTestCaseRule {test_case_name: dist.python-versions.py3_support}

Puede encontrar más información sobre este archivo en la documentación de Greenwave sobre políticas específicas de paquete.

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