☰

Bitbucket a Gitlab Webhook para activar la canalización

tag-icon • tag-icon gitlab bitbucket gitlab-runner
Bitbucket a Gitlab Webhook para activar la canalización

Tenemos seguidoresen las instalacionesEscenario: desarrolladores trabajando en Bitbucket en aplicaciones, operadores trabajando en Gitlab para cosas "Gitops". Nos gustaría automatizar las compilaciones y la implementación a través de nuestro proceso de Gitlab y buscar formas de implementarlo. La parte de construcción ya funciona. Pero nos gustaría distinguir entre sucursales: no todas las sucursales deberían implementarse, especialmente la producción se implementaría manualmente.

Dado que el webhook contiene la rama que intenté configurar en la etapa de implementación:

only:
  - dev

así como

  rules:
    - if: '$TOKEN_BRANCH != $PROD_BRANCH'

Pero en ambos sentidos el proceso de implementación aún está activado.

Se me ocurrieron dos soluciones:

Una opción sería reflejar el repositorio de Bitbucket a través del "enganche posterior a la confirmación", pero por un lado este complemento tiene costos y, por otro lado, necesita un segundo complemento para la duplicación, y el único que puedo encontrar no se mantiene. más extenso.

La segunda opción sería obtener una licencia de Gitlab Ultimate para poder utilizar "pull mirroring", que también podría activarse a través del webhook de Bitbucket.

Dado que no tenemos uso en la duplicación del repositorio y el único caso de uso sería poder usar la canalización de Gitlab en un "repositorio local" donde deberían funcionar todas las formas anteriores de diferenciar la rama para la implementación, preferiría encontrar una manera con los recursos ya disponibles.

¡Feliz de escuchar tu opinión sobre esto!

EDITAR: partes de la tubería:

variables:
  PROD_BRANCH: main

before_script:
  - TOKEN_BRANCH=$(cat $TRIGGER_PAYLOAD | jq -r '.changes[0].ref.displayId')

deploy:
  stage: deploy
  tags:
    - openshift
  rules:
    - if: $TOKEN_BRANCH != $PROD_BRANCH
  • echo $TOKEN_BRANCH devuelve "principal".
  • en reglas: esta parte de la canalización solo se activa si la siguiente afirmación es verdadera.
  • Dado que "main == main" y no "!=", la etapa de "implementación" de la canalización no debe ejecutarse. Pero es...

varias variantes

rules:
  - if: '$TOKEN_BRANCH !~ $PROD_BRANCH'

rules:
  - if: '$TOKEN_BRANCH =~ $PROD_BRANCH'
    when: never

en estos casos sucede lo contrario: la canalización nunca tiene una etapa de implementación; ni siquiera muestra la etapa en la vista "canalizaciones" en Gitlab.

Respuesta1

Encontré una solución funcional:

Después de que las "reglas" no funcionaron, ahora uso un "bucle if" en la parte del script de la etapa de implementación. Entonces, la etapa de implementación se activa cada vez, pero la lógica (= la implementación) solo se realiza si el token contiene la etapa respectiva.

deploy-to-test:
  stage: deploy
  variables:
    PROD: master
  tags:
    - openshift
  script:
    - >
      if [ "$TOKEN_BRANCH" != "$PROD" ]; then
      ---logic---
      else
        echo "skipping ..."
      fi

información relacionada