Esta semana tuve la tarea de modificar los pipelines que usamos en el trabajo para que no se despliegue en cada rama creada una API nueva, lo cual suena muy util pero ya en la practica no era tan redituable ya que no eran muy usadas y provocaban posibles errores en el cluster de K8s.
Al inicio pensé que seria algo simple ya que e podido interactuar con los archivos proporcionados por gitlab con el uso de variables de entorno pero al enfrentarme al problema descubrir que no era el caso ya que agregar una variable mataba todos los reviews lo cual no estaba buscando, entonces cambie mi problema y en lugar de permitirlo con una variable que el programador envié recordé que puedo volver manual la ejecución de alguna tarea en los pipeline dando como resultado el primer ejemplo:
include:
- template: Auto-DevOps.gitlab-ci.yml
review:
when: manual
De esta forma todos los review son manuales y no se están desplegando todo el tiempo, pasando ese control al programador.
Hay ocurrió otro problema ya que tenemos el habiente de dev que es llamado como review/dev lo cual hace que te pregunte si lo quieres ejecutar, eso no es le funcionamiento que necesitamos ya que al hacer un merge a dev debería de subir en automático para solucionar eso use otras reglas dando como resultado el archivo final que cumple con todas las expectativas.
review:
rules:
- if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
when: never
- if: '$CI_COMMIT_BRANCH == "dev"'
when: on_success
- if: '$CI_COMMIT_TAG || $CI_COMMIT_BRANCH'
when: manual
Como últimos cambios se agrega que si el pipeline que se correo es la rama por default no se va a ejecutar el trabajo pero si es un Tag o un commit a cualquier rama se cree el trabajo pero se necesite la ejecución manual.
Top comments (0)