web-dev-qa-db-fra.com

Dans GitLab CI, existe-t-il une variable pour la branche cible d'une demande de fusion?

Dans mon pipeline, j'aimerais avoir un travail exécuté uniquement si la branche cible Merge Requests est une certaine branche, par exemple master ou release.

Est-ce possible?

J'ai lu https://docs.gitlab.com/ee/ci/variables/ et à moins que j'ai raté quelque chose, je ne vois rien qui puisse aider.

gitlabgitlab-ci
7
Charlie

Gitlab CI est agnostique des demandes de fusion (pour l'instant). Étant donné que le pipeline s'exécute sur la branche d'origine, vous ne pourrez pas récupérer la destination.

1
djuarez

Mise à jour: 2019-03-21

GitLab a des variables pour les informations de demande de fusion depuis la version 11.6 ( https://docs.gitlab.com/ce/ci/variables/ voir les variables commencent par CI_MERGE_REQUEST_). Mais, ces variables ne sont disponibles que dans merge request pipelines. ( https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html )

Pour configurer un travail CI pour une demande de fusion, nous devons définir only: merge_request sur nos jobs pour demande de fusion. Et puis nous pouvons utiliser CI_MERGE_REQUEST_* variables dans ces emplois.

Le plus gros écueil ici est only: merge_request a un comportement complètement différent de la normale only/except paramètres.

habituel only/except paramètres: ( https://docs.gitlab.com/ce/ci/yaml/README.html#onlyexcept-basic )

  1. only définit les noms des branches et des balises pour lesquelles le travail sera exécuté.
  2. except définit les noms des branches et des balises pour lesquelles le travail ne sera pas exécuté.

only: merge_request: ( https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html#excluding-certain-jobs )

Le comportement du only: merge_requests le paramètre est tel que seuls les travaux avec ce paramètre sont exécutés dans le contexte d'une demande de fusion; aucun autre travail ne sera exécuté.

J'ai eu du mal à réorganiser les emplois pour les faire fonctionner comme avant avec only: merge_request existe sur n'importe quel travail. Ainsi, j'utilise toujours le one-liner dans ma réponse d'origine pour obtenir des informations MR dans un travail CI.

Réponse originale:

Non.

Mais GitLab a un plan pour cette fonctionnalité au deuxième trimestre 2019: https://gitlab.com/gitlab-org/gitlab-ce/issues/23902#final-assumptions

Actuellement, nous pouvons utiliser une solution de contournement pour y parvenir. La méthode est telle que la réponse de Rekovni l'a décrite, et elle fonctionne réellement.

Il y a une simple ligne, obtenez la branche cible d'un MR à partir de la branche actuelle:

script: # in any script section of gitlab-ci.yml
  - 'CI_TARGET_BRANCH_NAME=$(curl -LsS -H "PRIVATE-TOKEN: $AWESOME_GITLAB_API_TOKEN" "https://my.gitlab-instance.com/api/v4/projects/$CI_PROJECT_ID/merge_requests?source_branch=$CI_COMMIT_REF_NAME" | jq --raw-output ".[0].target_branch")'

Explication:

CI_TARGET_BRANCH_NAME est une variable nouvellement définie qui stocke le nom de branche cible résolu. La définition d'une variable n'est pas nécessaire pour diverses utilisations.

AWESOME_GITLAB_API_TOKEN est la variable configurée dans la configuration des variables CI/CD du référentiel. Il s'agit d'un jeton d'accès personnel GitLab (créé dans les paramètres utilisateur) avec une portée api.

À propos des options de curl: -L rend curl conscient des redirections HTTP. -sS rend la boucle silencieuse (-s) mais afficher (-S) les erreurs. -H spécifie les informations d'autorité accédant à l'API GitLab.

L'API utilisée pourrait être fondée en https://docs.gitlab.com/ce/api/merge_requests.html#list-project-merge-requests . Nous utilisons le source_branch attribut pour déterminer sur quel pipeline actuel MR s'exécute. Ainsi, si une branche source a plusieurs MR vers une branche cible différente, vous souhaiterez peut-être changer la partie après | et faites votre propre logique.

À propos de jq ( https://stedolan.github.io/jq/ ), il s'agit d'un simple outil CLI pour gérer les choses JSON (ce que l'API GitLab renvoie). Vous pouvez utiliser node -p ou toute méthode que vous souhaitez.

11
frantic1048

Si c'est ce que vous recherchez vraiment, il pourrait y avoir un moyen extrêmement compliqué (non testé) que vous pouvez atteindre en utilisant API de demande de fusion et variables CI .

Avec une étape de workflow/build quelque chose comme:

  1. Créer une demande de fusion à partir de feature/test à master
  2. Lancer une construction
  3. À l'aide de l'API (dans un script), récupérez toutes les demandes de fusion ouvertes du projet en cours à l'aide de CI_PROJECT_ID variable et filtrer par source_branch et target_branch.
  4. S'il y a une demande de fusion ouverte avec le source_branch et target_branch étant feature/test et master respectivement, continuez avec la construction, sinon sautez simplement le reste de la construction.

Pour utiliser l'API, je ne pense pas que vous puissiez utiliser le CI_JOB_TOKEN variable à authentifier, vous devrez donc probablement créer votre propre jeton d'accès personnel et le stocker en tant que variable CI à utiliser dans le travail de génération.

J'espère que cela t'aides!

3
Rekovni

Depuis GitLab 11.6, il y a CI_MERGE_REQUEST_TARGET_BRANCH_NAME .

1
Gajus