Etapas y tareas

En la siguiente tabla se enumeran las tareas que se ejecutan en un PR Pipeline. Además, la tabla también proporciona una visión general de cada una de estas etapas:

• Tarea o etapa: hace referencia al nombre de la etapa tal como se define en el archivo de configuración .pipeline-config.yaml.

• Descripción breve: proporciona una explicación concisa de las acciones realizadas durante la ejecución de la etapa.

• Personalización permitida: indica si los usuarios tienen la flexibilidad de modificar o sustituir el comportamiento predeterminado de la etapa insertando un script personalizado en el archivo .pipeline-config.yaml.

• Implementación de referencia por defecto: Indica si los DevSecOps pipelines vienen con una implementación predefinida o por defecto para la etapa. Notablemente, para ciertas etapas como unit-tests o setup, el DevSecOps pipeline no ofrece ninguna implementación out-of-the-box. En su lugar, los usuarios deben proporcionar scripts personalizados o código adaptado a los requisitos de su aplicación.

• Recopilación de pruebas: indica si la etapa realiza la recopilación de pruebas estándar. Cuando DevSecOps Pipeline proporcionan una implementación de referencia para una etapa, la recopilación de pruebas se realiza out-of-the-box. Sin embargo, si Usuario elige modificar o sustituir estas etapas predefinidas, debe asegurarse de que sus implementaciones personalizadas incluyan la recopilación de pruebas adecuada. La misma responsabilidad recae en los usuarios para las etapas en las que el DevSecOps pipeline no proporciona una implementación out-of-the-box, necesitando que ellos realicen la recopilación de pruebas. La columna indica la entidad (User/Pipeline) responsable de llevar a cabo la recopilación de pruebas.

• Omitir permisible (aplicable a la versión > = v10): indica si los usuarios pueden optar por no ejecutar esta etapa estableciendo la propiedad de omisión en true en .pipeline-config.yaml. Sin embargo, se recomienda precaución al utilizar esta característica, especialmente para las etapas diseñadas para recopilar pruebas. Omitir estas etapas puede hacer que falten pruebas esenciales para la compilación.

Para obtener más información sobre cómo personalizar las etapas utilizando el archivo .pipeline-config.yaml, consulte Scripts personalizados y Parámetros de interconexión.

Detectar exploración de secretos

La herramienta IBM Detect Secrets identifica dónde se ven los secretos en el código de la app. Encontrará más información sobre cómo configurar el repositorio para el escaneo aquí.

Exploraciones y comprobaciones en las comprobaciones de conformidad

| Comprobación del cumplimiento del repositorio | Comprueba que la configuración de protección de la rama es correcta. |

Estos scripts se ejecutan en todos los repositorios de aplicaciones de los que la interconexión tiene constancia. Para añadir repositorios a estas exploraciones, utilice la interfaz pipelinectl que se proporciona en la etapa de configuración.

Para obtener más información sobre la salida esperada de las etapas del script de usuario, consulte Scripts personalizados.

Trabajos de tareas

Utilización de los cambios PR/MR para el repositorio de configuración de canalizaciones

Si el PR pipeline debe considerar los cambios de los archivos de configuración/scripts que vienen del PR/MR entonces, el config repo y la rama deben estar vacíos, lo que puede establecerse como se indica a continuación:

• Las variables env one-pipeline-repo, one-pipeline-config-repo y pipeline-config-repo están vacías o no se especifican en las variables env
• Las variables env one-pipeline-config-branch y pipeline-config-branch están vacías o no están especificadas en las variables env.

Se fusionan las solicitudes de extracción con problemas

Puede utilizar los derechos de administrador para fusionar solicitudes de extracción con comprobaciones de estado con error en el repositorio. Sin embargo, estas solicitudes de extracción registran una failure como resultado de sus pruebas para la tarea con error. Este resultado se incluye en el resumen de las pruebas y en la descripción de la solicitud de cambio.

Permitir la recopilación de pruebas en el proceso de relaciones públicas

La canalización de las relaciones públicas apoya la recopilación de pruebas junto con la gestión de problemas. Por defecto, el canal de relaciones públicas no recopila pruebas ni abre incidencias, pero los usuarios pueden optar por esta función. Para habilitar la recopilación de pruebas y la gestión de incidencias, establezca la variable de entorno collect-evidence-in-pr como una de las siguientes enum:

• none: (por defecto) Establecer collect-evidence-in-pr a none, para evitar la recogida de pruebas en la tubería PR.
• all: Establezca collect-evidence-in-pr en all para recopilar todas las evidencias independientemente del estado de la canalización del RP. Las incidencias se abrirán, actualizarán o cerrarán según el script collect-evidence.
• success: Establezca collect-evidence-in-pr en success para recopilar evidencias solo si todo el canal de relaciones públicas se ejecutó correctamente. Si la cadena de relaciones públicas falla, las pruebas no se recopilarán ni se publicarán en el almacén de pruebas, y la gestión de problemas no se llevará a cabo.

Nota: Dado que, las tuberías PR se ejecutan generalmente con bastante frecuencia, la elección del modo correcto de collect-evidence-in-pr ahorrará de la recopilación de pruebas innecesarias. Se sugiere seleccionar el modo success durante la fase de desarrollo o en casos en los que se prevean fallos, para evitar la recogida de pruebas si falla la tubería.

Si la canalización PR desencadena una canalización Async, no se admite el modo collect-evidence-in-pr establecido en success. En caso de que el canal PR active un canal asíncrono, establezca collect-evidence-in-pr en all para recopilar evidencias.

Nota: Si el repositorio de la aplicación es un repositorio GitLab y la solicitud de fusión (MR) que se está contribuyendo proviene de un repositorio bifurcado, el usuario deberá proporcionar un valor para la variable git-token de entorno que tenga acceso tanto al repositorio de origen como al de destino para establecer los estados adecuados en la solicitud de fusión. Esto significa que el token git tendría que pertenecer a un usuario que sea colaborador tanto en el repositorio base como en el repositorio bifurcado y que el token tenga permisos para establecer el estado en una confirmación.

CVE en PR

Cuando se crea un PR y el canal de PR encuentra vulnerabilidades, el canal añade la información de la vulnerabilidad como la gravedad, el identificador cve, el paquete junto con su descripción y la solución si está disponible como comentario. Esto permite a los usuarios comprobar rápidamente las vulnerabilidades que deben corregirse en el PR, en lugar de tener que revisar los registros de las canalizaciones.

Para activar/desactivar esta función en el proceso de RP, existe un indicador opcional opt-in-pr-updates. Esta opción está activada por defecto.

Configuración de un canal de relaciones públicas para gestionar las relaciones públicas de la cola de fusión de Github

Una cola de fusiones es una función de Github que ayuda a aumentar la velocidad mediante la automatización de fusiones de solicitudes de extracción en una rama ocupada y asegurando que la rama nunca se rompa por cambios incompatibles. Más información sobre la configuración y el uso de Github Merge Queue aquí.

Aunque el objetivo de «Merge Queue» es aumentar la velocidad, es importante tener en cuenta que, para una solicitud de incorporación de cambios (PR) de « Git » determinada, el proceso de la PR se ejecutará dos veces: primero se ejecutará la PR «estándar». Una vez completado, ejecuta la solicitud de incorporación de cambios (PR) de la cola de fusión.

Resumen de la carga útil PR

Propiedades del entorno extraídas de la carga útil PR

Las siguientes variables de entorno se derivan actualmente de la carga útil PR y se utilizan activamente:

Estos valores se inyectan como variables de entorno para simplificar el acceso durante la ejecución en flujos de trabajo automatizados.

La carga útil PR incluye muchos campos adicionales además de los enumerados anteriormente. Sin embargo, actualmente sólo se aprovecha con fines operativos el subconjunto extraído. En caso necesario, puede proporcionarse acceso a la carga útil completa para casos de uso avanzado o futuras ampliaciones.