Guía práctica de implementación a gran escala de CI/CD a nivel empresarial de Jihu GitLab (1)

Tabla de contenido

referencia de plantilla, lo que reduce la redundancia de código y mejora la escalabilidad de la compilación de CI/CD

Problema 1: código redundante y prácticas ineficientes

Problema 2: Difícil de mantener y gran carga de trabajo

➤ local

➤ archivo

➤ remoto

➤ plantilla

Beneficio 1: una modificación entra en vigor en muchos lugares

Beneficio 2: Construcción eficiente, simple y conveniente

Componente que crea una única fuente de confianza para CI/CD Pipeline y simplifica la construcción de CI/CD Pipeline

Construcción de almacén de componentes.

Liberación del componente

Referencia al componente

 Runner, una herramienta para la construcción eficiente de CI/CD

Exclusivo + Compartido, opciones más flexibles

Ampliar y reducir dinámicamente la capacidad para mejorar la utilización de recursos

Línea de montaje de cumplimiento, que ayuda al uso seguro y conforme de las líneas de montaje

---

JiHu GitLab CI está integrado en la plataforma integrada JiHu GitLab, brinda capacidades de CI/CD listas para usar y también es una de las herramientas de CI que adoran muchos usuarios. El mecanismo de diseño único de Jihu GitLab CI y las características funcionales a nivel empresarial pueden ayudar a las empresas a mejorar la eficiencia de la construcción de CI/CD y reducir los costos de mantenimiento de la tubería al implementar prácticas de CI/CD a gran escala , manteniendo al mismo tiempo un cumplimiento de seguridad suficiente .

Este artículo comienza con la construcción de CI/CD Pipeline y describe el uso de Jihu GitLab CI en tres aspectos principales:

1. Utilice  template , component para acortar el tiempo de escritura de la canalización y mejorar la mantenibilidad;

2. Utilice la jugabilidad "elegante" de Runner para satisfacer las necesidades operativas de CI/CD Pipeline en diferentes escenarios y, al mismo tiempo, reducir los costos de uso;

3. Utilice un marco de cumplimiento para garantizar el uso conforme de CI/CD Pipeline.

referencia de plantilla, lo que reduce la redundancia de código y mejora la escalabilidad de la compilación de CI/CD

Dentro de una empresa, un escenario muy común es que diferentes equipos o diferentes líneas de productos tienen sus propios proyectos únicos, y cada proyecto tiene su correspondiente canal de CI/CD. A medida que aumenta el número de proyectos, el número de canales seguirá aumentando. , puede haber cientos o incluso miles de líneas de montaje dentro de una empresa.

Debido a que la canalización de CI/CD es una forma automatizada de entrega de software (desde la codificación hasta la conexión en línea), la mayoría de las canalizaciones tendrán un grado relativamente alto de similitud , y algunas etapas o trabajos son incluso exactamente iguales, como en los escenarios de entrega nativa de la nube. La aplicación debe empaquetarse en un espejo. El código para compilar usando Jihu GitLab CI es el siguiente:

build:
  image: docker:latest
  stage: build
  services:
    - docker:20.10.7-dind
  script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:1.0.0 .
    - docker push $CI_REGISTRY_IMAGE:1.0.0

Además, si todos son proyectos de Java o Golang, los comandos de compilación o prueba pueden ser similares. Esta "repetición" aumentará a medida que aumente el pipeline, y también surgirán los siguientes problemas:

Problema 1: código redundante y prácticas ineficientes

Si cada canalización tiene una etapa o trabajo similar con aproximadamente 10 líneas de código, entonces la cantidad de códigos duplicados en cientos o miles de canalizaciones es de decenas de miles. Este tipo de redundancia de código es en sí misma una práctica ineficiente en el campo del desarrollo de software: si no se refactoriza a tiempo, se convertirá en deuda técnica a medida que evolucione el proyecto.

Problema 2: Difícil de mantener y gran carga de trabajo

En el proceso de optimización de la canalización de CI/CD, algunas partes de la canalización deben modificarse, como actualizar la versión dind o cambiar el método de compilación de dind a kaniko para construir la imagen de forma segura, luego se debe enviar el código correspondiente. ser cambiado convertirse en:

  services:
    - docker:24.0.3-dind

y:

build:
  stage: build
  image:
    name: registry.jihulab.com/jh-xiaomage-devops/go-demo/kaniko:debug
    entrypoint: [""]
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
    - >-
      /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination "${CI_REGISTRY_IMAGE}:1.0.0"

En este momento, todas las canalizaciones deben transformarse. La transformación de cientos o incluso miles de canalizaciones supondrá una gran carga de trabajo y el proceso de "copiar y pegar" de una gran cantidad de código es difícil de evitar sin errores.

En el campo de la investigación y el desarrollo de software, una forma importante de resolver el código redundante es mediante la abstracción + reutilización: es decir, abstraer el mismo (o similar) contenido en plantillas, "almacenar" las plantillas en un lugar determinado y simplemente consultarlas. las plantillas en otros lugares. Eso es todo .

Lo mismo ocurre con CI/CD Pipeline. La plantilla GiFox GitLab es la función de motor de plantillas incorporada de GiFox GitLab CI, que puede almacenar plantillas abstractas en el almacén del proyecto y otros proyectos pueden hacer  include referencia a las plantillas a través de la sintaxis.

El uso de la plantilla Jihu GitLab es relativamente flexible: primero debe "crear" la plantilla, es decir, extraer el código "duplicado" y guardarlo en un archivo YAML. Por ejemplo, el contenido de compilación de la imagen anterior se puede escribir en un archivo docker-image-build.gitlab-ci.yml. Próxima  include cita de uso. Dependiendo de dónde esté almacenada la plantilla, include hay cuatro formas de hacer referencia a ella:

➤ local

Las plantillas se encuentran en el proyecto actual y  local se hace referencia a ellas mediante palabras clave . La sintaxis de uso es la siguiente:

include:  
  - local: '/templates/docker-image-build.gitlab-ci.yml'

➤ archivo

La plantilla y el proyecto se encuentran en la misma instancia, pero en repositorios diferentes, y se  file hace referencia a ellos mediante palabras clave . La sintaxis de uso es la siguiente:

include  
  - project: xiaomage/templates  
  - ref: main    
  file: /templates/docker-image-build.gitlab-ci.yml

➤ remoto

Referencias a canalizaciones en almacenes remotos, generalmente entre diferentes instancias . La sintaxis de uso es la siguiente:

include:   
  - remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'

➤ plantilla

Una referencia a la plantilla incorporada de JiHu GitLab . Basándose en sus muchos años de experiencia, GitLab ha acumulado muchas plantillas que se pueden reutilizar directamente y se pueden utilizar mediante la sintaxis de la plantilla. La más típica es la referencia de la plantilla Jihu GitLab DevSecOps. GitLab DevSecOps tiene funciones de escaneo de claves, escaneo de dependencias, SAST, DAST, escaneo de imágenes de contenedores, pruebas fuzz y detección de cumplimiento de licencias. Todas las funciones se pueden activar con dos líneas de código.

Por lo tanto, utilizar una plantilla puede aportar los siguientes beneficios:

Beneficio 1: una modificación entra en vigor en muchos lugares

Si necesita optimizar el contenido de la canalización, como  dind actualizar la versión de, solo necesita realizar modificaciones en la plantilla, y otros lugares a los que se hace referencia entrarán en vigor, y realmente se dará cuenta de "modificar en un lugar, surtir efecto en varios lugares". , lo que evita por completo La duplicación de trabajo causada por "cambiar una vez, modificar en todas partes" también reducirá la redundancia de la canalización.

Beneficio 2: Construcción eficiente, simple y conveniente

La plantilla puede lograr un anidamiento de varios niveles, es decir, se hace referencia a las plantillas dentro de las plantillas. La ventaja de esto es que el contenido de la plantilla puede ser detallado, puede ser una etapa o un trabajo, por ejemplo, la construcción de la imagen del contenedor es una plantilla y el escaneo de seguridad de la imagen del contenedor es otra plantilla. Si desea construir una tubería para un nuevo proyecto, puede usar directamente varias plantillas para "construir bloques de construcción" para completar rápidamente la construcción de la tubería y luego realizar algunos cambios en los parámetros o procesos de acuerdo con el proceso de construcción real de el proyecto.

Por supuesto, para utilizar las plantillas de manera eficiente, hay otro problema al que se debe prestar atención: la sobrescritura de variables en las plantillas .

Para utilizar plantillas de manera flexible, utilice el mismo conjunto de plantillas para crear varias instancias diferentes. La clave está en el uso de variables en la plantilla. Por ejemplo, al crear una imagen de contenedor, la etiqueta puede diferir de una versión a otra. En este caso, la etiqueta se puede configurar como una variable:

variables:
  IMAGE_TAG: 1.0.0

build:
  image: docker:latest
  stage: build
  services:
    - docker:20.10.7-dind
  script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG .
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG

Simplemente sobrescriba la variable directamente en el punto de referencia:

variables:
  IMAGE_TAG: "2.0.0"

include: 
  - remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'

1.0.0 Después de sobrescribir, el valor de la etiqueta de imagen cambia  respecto al valor predeterminado  2.0.0 , lo que puede cumplir con los requisitos de diferentes escenarios y es eficiente y flexible.

Componente que crea una única fuente de confianza para CI/CD Pipeline y simplifica la construcción de CI/CD Pipeline

El uso de plantillas reduce en gran medida la dificultad para los usuarios a la hora de crear tuberías de CI/CD. A través del modo de cobertura de referencia + parámetros, las tuberías correspondientes a los escenarios se pueden construir rápidamente. Sin embargo, actualmente no existe una única fuente confiable de plantillas que facilite a los usuarios encontrar lo que quieren Mientras usan Pipeline, los usuarios que están dispuestos a contribuir no pueden contribuir con las plantillas disponibles para construir conjuntamente un ecosistema de Pipeline próspero.

Con este fin, Jihu GitLab ha lanzado la función CI/CD Component, cuyo propósito es crear una única fuente confiable para CI/CD Pipeline al convertir diferentes canalizaciones (o trabajos separados) en diferentes componentes y luego publicarlos en el almacén de componentes. Los usuarios pueden buscar en este almacén el componente que desean. Pueden hacer referencia a él directamente al crear la canalización. La referencia de múltiples componentes puede construir rápidamente toda la canalización completa. Este es un gran cambio. Mejorar la experiencia del usuario al usar CI/ CD.

Lo que es más importante es que los usuarios pueden publicar algunas canalizaciones excelentes (o trabajos individuales) que crean que se han practicado en forma de componentes en el almacén de componentes, y crear conjuntamente un próspero ecosistema de canalizaciones de CI/CD a través de las continuas contribuciones e iteraciones de diferentes usuarios., y finalmente construir una única fuente confiable para el CI/CD Pipeline interno de la empresa , que no solo mejora la eficiencia de la construcción del CI/CD Pipeline, sino que también mejora en gran medida la seguridad.

Nota: El componente CI/CD es actualmente experimental.

Diagrama de componentes CI/CD

Por lo tanto, el núcleo del componente es: la construcción del almacén de componentes, el lanzamiento del componente y la referencia del componente .

Construcción de almacén de componentes.

Cree un repositorio de componentes inicial creando un repositorio de GitLab y marcándolo como repositorio de componentes. El repositorio requiere al menos dos archivos  README.md y  template.yml:

• README.md Los componentes contenidos en el almacén se pueden describir para facilitar el aprendizaje y uso de los usuarios;

• template.yml Es el contenido específico del componente.

Se pueden distinguir diferentes componentes a través de diferentes estructuras de directorios (rama, etiqueta, etc.), como por ejemplo:

├── template.yml
├── README.md
├── .gitlab-ci.yml
├── forntend/
│   └── template.yml
└── backend/
    └── template.yml

El directorio anterior indica que hay tres componentes disponibles en este almacén de componentes:

• template.yml El componente representado en el directorio raíz  ;

• template.yml El componente representado en el directorio frontend  ;

• template.yml El componente representado en el directorio backend  .

Puede marcar un almacén como almacén de componentes a través de Proyecto → Configuración → General → Visibilidad, Funciones del proyecto, General → Habilitar recursos del directorio CI/CD.

Liberación del componente

Si necesita publicar un componente, debe escribir el contenido correspondiente en un  template.yml archivo y luego enviar el archivo al almacén de componentes. Tomando la construcción de la imagen anterior como ejemplo, escriba el siguiente contenido en un archivo  template.yml :

spec:  
  inputs:    
    stage:      
      default: test    
    image:      
      default: docker:latest    
    tags:      
      default: tags    
    image_tag:      
      default: 1.0.0
      
component-job-build-image:  
  image: $[[ inputs.image ]]  
  stage: $[[ inputs.stage ]]  
  tags:    
    - $[[ inputs.tags ]]  
  script:     
    - docker login -u "$REGISTRY_USER" -p "$REGISTRY_PWD" REGISTRY_URL    
    - docker build -t dllhb/cicd-component:$[[ inputs.image_tag ]] .    
    - docker push dllhb/cicd-component:$[[ inputs.image_tag ]]

Luego empújelo  jh.instance.url/username/component-project al directorio. Descripción de parámetros:

• jh.instance.url: Dirección de instancia de implementación privada de Jihu GitLab;

• username：Nombre de usuario de Jihu GitLab;

• component-project:nombre del almacén de componentes.

El componente anterior está ubicado en el directorio raíz del almacén y tiene un  component-job-build-image trabajo.

Referencia al componente

Si desea hacer referencia al componente publicado anteriormente en otros Pipelines,  .gitlab-ci.yml utilice la siguiente sintaxis para hacer referencia a él:

include:  
  - component: jh.instance.url/username/component-project@main    
  inputs:      
    stage: build      
    image: docker:latest      
    tags: cicd      
    image_tag: 2.0.0
    
stages: [build]

Las cosas a tener en cuenta son:

• include Escriba completamente la ruta del componente (es decir,  tempate.yml la ruta existente) en  él y use @ para dejar claro a qué versión del componente se hace referencia (puede representarse mediante ramas, hash de confirmación, etiquetas, etc.);

• inputs Escriba parámetros específicos en . 

Active el canal CI/CD y podrá ver que  component-job-build-image jobla ejecución se realizó correctamente:

De manera similar, si desea  dind cambiar el método de compilación  kaniko, no necesita reemplazar el contenido del componente anterior, solo necesita publicar un componente con temática kaniko nuevamente.

Hay muchas formas de lograr esto, como colocarlo  template.yml en otro directorio del almacén de componentes (no en el directorio raíz, porque ya dind hay ), ramas y etiquetas para indicar que se trata de un componente diferente. ; por ejemplo, para el componente anterior , la rama principal representa  dind el componente, luego puede crear una nueva  kaniko rama para almacenar el componente correspondiente a kaniko y, finalmente,  .gitlab-ci.yml especificar la rama al hacer referencia a ella:

include:  
  - component: jh-jhma.gitlab.cn/cicd-component/cicd-component-demo@kaniko   
  inputs:      
    stage: build      
    image: gcr.io/kaniko-project/executor:debug      
    tags: cicd      
    image_tag: 2.0.0
    
stages: [build]

dind Por supuesto, también se debe cambiar  la imagen de la original  kinako, esto solo requiere modificar  inputs los parámetros.

Puede obtener los mismos resultados ejecutando una canalización de CI/CD.

La introducción del componente inició un nuevo paradigma para GitLab CI/CD. Este enfoque de crear una única fuente de confianza para CI/CD Pipeline a través de las contribuciones de los usuarios es de gran ayuda para los usuarios en la construcción de un Pipeline completo. No solo acelera la construcción de CI/CD Pipeline, sino que también reduce en gran medida el costo para los usuarios. para aprender la complicada sintaxis YAML.

Todos los códigos mostrados anteriormente están almacenados en la instancia de implementación privatizada de Jihu GitLab y la dirección es  https://jh-jhma.gitlab.cn/cicd-component .

 Runner, una herramienta para la construcción eficiente de CI/CD

Runner es un componente importante de GitLab CI, que puede ayudar a ejecutar trabajos definidos en la canalización de CI/CD . Cuando los desarrolladores envían cambios de código, Jihu GitLab "notificará" al Runner para que  .gitlab-ci.yml complete la construcción, prueba, implementación, etc. del código modificado de acuerdo con los pasos de canalización definidos. Durante este proceso, el Runner seguirá al ejecutor seleccionado (como el shell para PowerShell), la ventana acoplable para contenedores, etc.) para ejecutar trabajos en diferentes entornos. Con respecto a la selección de ejecutores, consulte Jihu GitLab Executor Network .

Runner es como un "agente" que acepta solicitudes del lado del "servidor" (instancia de Jihu GitLab). Por lo tanto, para satisfacer las necesidades de diferentes escenarios, Runner debe poder ejecutarse en diferentes métodos de instalación en diferentes sistemas operativos y diferentes CPU. arquitecturas.

Exclusivo + Compartido, opciones más flexibles

Runner se divide en dos categorías: propietarias y compartidas:

• Propietario: significa que Runner solo se usa para proyectos designados, generalmente usando cierta información del proyecto (token de registro de Runner) para registrar Runner en el proyecto correspondiente;

• Compartir: significa que el Runner es para toda la instancia de GitLab, lo que significa que todos los proyectos de la instancia completa pueden usar estos Runners. En cuanto a cómo usarlo, quién lo usa primero y quién lo usa después, lo implementa el Mecanismo de programación interno de GitLab.

Las mayores ventajas de los corredores propietarios son:

• Ahorre tiempo : el Runner dedicado solo ejecuta la canalización de CI/CD para el proyecto correspondiente, por lo que no es necesario hacer cola y esperar a que el Runner compartido ejecute la canalización de CI/CD. A medida que aumenta el número de proyectos y canalizaciones, las colas llevará mucho tiempo;

• Autónomo y controlable : el usuario instala el Runner propietario en un servidor que es controlable por el usuario. Durante el uso, si desea depurar el proceso de canalización o modificar la configuración del Runner, o incluso desea obtener algunos datos durante el proceso de ejecución. , puede iniciar sesión directamente en el Runner correspondiente para realizar operaciones.

Información de configuración del Runner propietario

Los beneficios de compartir Runner también son obvios: los usuarios no necesitan saber demasiada información sobre Runner, ni necesitan instalarlo y operarlo ellos mismos . Es una forma relativamente sencilla.

Por lo tanto, los usuarios pueden elegir diferentes métodos de Runner según sus propias necesidades para completar la operación de canalización de CI/CD correspondiente.

Ampliar y reducir dinámicamente la capacidad para mejorar la utilización de recursos

Runner puede estar estrechamente vinculado a la función de escalado dinámico de los recursos de la nube para lograr un escalado dinámico de Runner: cuando es necesario ejecutar una canalización de CI/CD, Runner usa algunos recursos (CPU, memoria, etc.) para ejecutar todos los trabajos. Canalización de CI/CD Una vez finalizada la operación (éxito o fracaso), se liberan los recursos correspondientes y se restaura el entorno.

Por ejemplo, puedes usar contenedores para ejecutar Runner, el más típico es usar Kubernetes para ejecutar Jihu GitLab Runner.

Al ejecutar CI/CD, Kubernetes creará dinámicamente un pod, y el pod generará los  .gitlab-ci.yml contenedores correspondientes según la etapa y la imagen correspondiente descritas en el archivo (todos los contenedores están en un pod y comparten los recursos internos del pod). de la canalización está Dentro del contenedor, cuando finaliza la canalización, el pod se eliminará y se liberarán los datos y recursos necesarios durante la operación.

Además, también puede utilizar productos sin servidor proporcionados por proveedores de nube para expandir dinámicamente la capacidad de Runner y mejorar la utilización de recursos.

Línea de montaje de cumplimiento, que ayuda al uso seguro y conforme de las líneas de montaje

También se encuentra un escenario durante el uso de canalizaciones: un determinado proceso requiere que se ejecuten todas las canalizaciones del proyecto. Por ejemplo, se debe realizar un análisis de seguridad de la imagen al final de la creación de la imagen. Si hay una vulnerabilidad de seguridad, la ejecución de es necesario terminar el oleoducto. La solución en este caso suele ser agregar un  include enlace de escaneo de imágenes de contenedor a la canalización para todos los proyectos. Sin embargo, a medida que aumenta el número de proyectos (cientos o incluso miles), esto significa una enorme cantidad de trabajo duplicado y la operación no puede estar garantizada la exactitud.

Y la solución correcta es: un canal de cumplimiento.

El canal de cumplimiento es una característica de seguridad integrada en el canal de CI/CD de GitLab que garantiza principalmente que todos los proyectos del grupo puedan ejecutar trabajos de cumplimiento específicos . Al configurar el marco de cumplimiento a nivel de grupo y seleccionar el trabajo de canalización de cumplimiento que debe ejecutar cada proyecto, todos los proyectos de este grupo ejecutarán este trabajo de cumplimiento, incluso los proyectos recién creados en este grupo. Los proyectos también realizan este trabajo de cumplimiento de forma predeterminada.

Para utilizar el canal de cumplimiento, primero debe configurar el marco de cumplimiento a nivel de grupo. En Grupos → Configuración → General → Marco de cumplimiento , seleccione Nuevo marco de cumplimiento, luego complete el nombre del marco de cumplimiento, la descripción, la configuración del canal de cumplimiento (es decir, dónde se almacena el canal de cumplimiento) y, finalmente, seleccione un color de fondo. Eso es todo.

Si este marco de cumplimiento se establece como el marco de cumplimiento predeterminado del grupo, todos los proyectos nuevos bajo este grupo usarán este marco de cumplimiento de forma predeterminada, ejecutarán este canal de cumplimiento de forma predeterminada y habrá una etiqueta de marco de cumplimiento en la página del proyecto. .

Luego, debe escribir el canal de cumplimiento en un proyecto de este grupo (como Compliance-Pipeline). Tomando como ejemplo la canalización de escaneo y creación de imágenes del contenedor,  .gitlab-ci.yml escriba el siguiente contenido en el archivo:

include: 
  - remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'
  - template: Security/Container-Scanning.gitlab-ci.yml

Todos los proyectos nuevos posteriores realizarán la creación y el escaneo de imágenes de contenedores, en lugar del proceso propio del proyecto.

Si desea que se ejecute la canalización propia del proyecto, solo necesita fusionar el contenido de la canalización de cumplimiento con el contenido de la canalización propia del proyecto. Por ejemplo, la canalización integrada necesita usar cosgin para firmar y verificar la imagen del contenedor empaquetado para evitar que la imagen sea manipulada:

stages:
  - singature
  - verfication

image-singature:
  stage: singature
  tags:
    - cosign
  image: 
    name: dllhb/cosign:1.0.0
    entrypoint: [""]
  before_script:
    - mkdir ~/.docker
    - cat "$DOCKER_CRED_FILE" > ~/.docker/config.json
    - cat "$COSIGN_KEY" > /tmp/cosign.key
    - export COSIGN_PASSWORD="$COSIGN_PASSWORD"
  script:
    - cosign sign --key /tmp/cosign.key $CI_REGISTRY_IMAGE:1.0.0

image-verfication:
  stage: verfication
  tags:
    - cosign
  image: 
    name: dllhb/cosign:1.0.0
    entrypoint: [""]
  before_script:
    - cat "$COSIGN_PUB" > /tmp/cosign.pub
    - export COSIGN_PASSWORD="$COSIGN_PASSWORD"
  script:
    - cosign verify --key /tmp/cosign.pub $CI_REGISTRY_IMAGE:1.0.0

El proceso anterior debe introducirse en el proceso de cumplimiento:

include:
  - project: 'Compliance-Pipeline-Group/regular-pipeline'
    file: '.gitlab-ci.yml'

Con el tiempo, los proyectos de otros proyectos de este grupo realizarán los cuatro pasos de empaquetado, escaneo, firma y verificación de imágenes de contenedores.

Por lo tanto, el marco de cumplimiento se selecciona para marcar ciertos proyectos que deben cumplir ciertos requisitos de cumplimiento o requerir supervisión adicional, y luego completar el trabajo de cumplimiento mediante la ejecución del proceso de cumplimiento.