Ce plugin permet à GitLab de déclencher des builds dans Jenkins lorsque le code est

validé ou que les demandes de fusion sont ouvertes/mises à jour. Il peut également
renvoyer l’état de build à GitLab.

Assistance aux utilisateurs

Relation avec GitLab Inc.
Ce plugin est un logiciel Open Source, développé sur une base bénévole par les
utilisateurs de Jenkins et GitLab. Il n’est pas officiellement pris en charge par
GitLab Inc. ou CloudBees Inc.

Versions de GitLab prises en charge

GitLab effectue une nouvelle version majeure environ tous les six à neuf mois, et
ils corrigent constamment les bogues et ajoutent de nouvelles fonctionnalités. Par
conséquent, nous ne pouvons pas prendre en charge ce plugin lorsqu’il est utilisé
avec des versions de GitLab antérieures à N-2, où N est la version majeure
actuelle.

Obtenir de l’aide
Si vous avez un problème ou une question sur l’utilisation du plugin, assurez-vous
d’utiliser la dernière version. Créez ensuite un problème dans le projet GitHub.

Pour activer la journalisation de débogage dans le plug-in :

Allez dans Jenkins -> Gérer Jenkins -> Journal système

Ajouter un nouvel enregistreur de journaux
Entrez 'GitLab plugin' ou ce que vous voulez pour le nom
Sur la page suivante, entrez 'com.dabsquared.gitlabjenkins' pour Logger, réglez le
niveau de journal sur FINEST, et enregistrez
Cliquez ensuite sur le journal de votre plugin GitLab, cliquez sur « Effacer ce
journal » si nécessaire, puis utilisez GitLab pour déclencher certaines actions
Actualisez la page de journal et vous devriez voir la sortie
Bogues/problèmes connus
Le plug-in suit les problèmes actuels avec le suivi des problèmes GitHub. Certains
problèmes sont signalés dans l’outil de suivi des problèmes Jenkins Jira. Lorsque
vous recherchez des problèmes existants, veuillez vérifier les deux emplacements.

Signaler un problème
Veuillez signaler les problèmes et les améliorations via l’outil de suivi des
problèmes GitHub.

Variables définies
Lorsque GitLab déclenche une build via le plugin, diverses variables
d’environnement sont définies en fonction de la charge utile JSON envoyée par
GitLab. Vous pouvez les utiliser dans toute la configuration de votre tâche. Les
variables disponibles sont les suivantes :

gitlabBranch
gitlabSourceBranch
gitlabActionType
gitlabUserName
gitlabUserUsername
gitlabUserEmail
gitlabSourceRepoHomepage
gitlabSourceRepoName
gitlabSourceNamespace
gitlabSourceRepoURL
gitlabSourceRepoSshUrl
gitlabSourceRepoHttpUrl
gitlabMergeCommitSha
gitlabMergeRequestTitle
gitlabMergeRequestDescription
gitlabMergeRequestId
gitlabMergeRequestIid
gitlabMergeRequestState
gitlabMergedByUser
gitlabMergeRequestAssignee
gitlabMergeRequestLastCommit
gitlabMergeRequestTargetProjectId
gitlabMergeRequestLabels
gitlabTargetBranch
gitlabTargetRepoName
gitlabTargetNamespace
gitlabTargetRepoSshUrl
gitlabTargetRepoHttpUrl
gitlabBefore
gitlabAfter
gitlabTriggerPhrase
NOTE: Ces variables ne sont pas disponibles dans les travaux Pipeline Multibranch.

Configuration globale du plugin

Authentification GitLab-to-Jenkins
Le plugin nécessite une authentification pour se connecter de GitLab à Jenkins.
Cela empêche les personnes non autorisées de déclencher des tâches.

Sécurité de l’authentification
Les APITOKENS et autres secrets NE DOIVENT PAS être envoyés via des connexions non
sécurisées. Ainsi, toutes les connexions DEVRAIENT utiliser HTTPS.

Remarque : Les certificats sont gratuits et faciles à gérer avec LetsEncrypt.

Configuration de l’authentification globale

Créez un utilisateur dans Jenkins qui dispose, au minimum, des autorisations
Job/Build
Connectez-vous en tant qu’utilisateur (cela est requis même si vous êtes un
utilisateur administrateur Jenkins), puis cliquez sur le nom de l’utilisateur dans
le coin supérieur droit de la page
Cliquez sur « Configurer », puis sur « Ajouter un nouveau jeton », et notez/copiez
l’ID utilisateur et le jeton API
Dans GitLab, lorsque vous créez des webhooks pour déclencher des tâches Jenkins,
utilisez ce format pour l’URL et n’entrez rien pour 'Secret Token' :
https://USERID:APITOKEN@JENKINS_URL/project/YOUR_JOB
Après avoir ajouté le webhook, cliquez sur le bouton « Tester », et il devrait
réussir
Configuration de l’authentification par projet
Si vous souhaitez créer des informations d’identification d’authentification
distinctes pour chaque travail Jenkins :

Dans la configuration de votre job Jenkins, dans la section de configuration de

GitLab, cliquez sur 'Avancé'
Cliquez sur le bouton « Générer » sous le champ « Jeton secret »
Copiez le jeton résultant et enregistrez la configuration de la tâche
Dans GitLab, créez un webhook pour votre projet, entrez l’URL du déclencheur (par
exemple ) et collez le jeton dans le champ Jeton
secrethttps://JENKINS_URL/project/YOUR_JOB
Après avoir ajouté le webhook, cliquez sur le bouton « Tester », et il devrait
réussir
Désactivation de l’authentification
Si vous souhaitez désactiver cette authentification (non recommandée) :
Dans Jenkins, allez dans Gérer Jenkins > Configurer le système
Faites défiler jusqu’à la section intitulée 'GitLab'
Décochez « Activer l’authentification pour le point de terminaison '/project' » -
vous pourrez désormais déclencher des tâches Jenkins à partir de GitLab sans avoir
besoin d’authentification.
Authentification Jenkins vers GitLab
VEUILLEZ NOTER : Cette configuration d’authentification n’est utilisée que pour
accéder à l’API GitLab afin d’envoyer l’état de build à GitLab. Il n’est pas
utilisé pour cloner des dépôts git. Les informations d’identification pour le
clonage (généralement des informations d’identification SSH) doivent être
configurées séparément, dans le plug-in git.

Ce plug-in peut être configuré pour envoyer des messages d’état de build à GitLab,
qui s’affichent dans l’interface utilisateur de la demande de fusion GitLab. Pour
activer cette fonctionnalité :

Créer un nouvel utilisateur dans GitLab

Donnez à cet utilisateur les permissions 'Maintainer' sur chaque dépôt auquel vous
souhaitez que Jenkins envoie l’état de construction
Connectez-vous ou « usurpez l’identité » de cet utilisateur dans GitLab, cliquez
sur l’icône/l’avatar de l’utilisateur et choisissez Paramètres
Cliquez sur 'Jetons d’accès'
Créez un jeton nommé par exemple 'jenkins' avec la portée 'api' ; L’expiration est
facultative
Copiez le jeton immédiatement, il n’est pas accessible après avoir quitté cette
page
Sur la page Configuration globale de Jenkins, dans la section Configuration GitLab,
indiquez l’URL de l’hôte GitLab, par ex. https://your.gitlab.server
Cliquez sur le bouton « Ajouter » pour ajouter des informations d’identification,
choisissez « Jeton d’API GitLab » comme type d’identification, puis collez la clé
API de votre utilisateur GitLab dans le champ « Jeton d’API »
Cliquez sur le bouton « Tester la connexion » ; Il devrait réussir
Configuration de la tâche Jenkins
Il y a deux aspects de votre travail Jenkins que vous pouvez modifier lorsque vous
utilisez GitLab pour déclencher des travaux. La première est la configuration Git,
où Jenkins clone votre dépôt git. Le plugin GitLab définira certaines variables
d’environnement lorsque GitLab déclenche une build, et vous pouvez les utiliser
pour contrôler le code cloné à partir de Git. La seconde est la configuration pour
renvoyer l’état de build à GitLab, où il sera visible dans l’interface utilisateur
de la demande de commit et/ou de fusion.

Configuration des paramètres

Si vous souhaitez pouvoir exécuter des tâches à la fois manuellement et
automatiquement via des webhooks GitLab, vous devrez configurer les paramètres de
ces tâches. Si vous souhaitez uniquement déclencher des tâches à partir de GitLab,
vous pouvez ignorer cette section.

Tous les paramètres GitLab que vous créez auront toujours la priorité sur les
valeurs envoyées par le webhook, sauf si vous utilisez le plug-in EnvInject pour
mapper les valeurs du webhook sur les paramètres de la tâche. Cela est dû aux
modifications apportées pour corriger les vulnérabilités de sécurité, avec des
modifications qui ont atterri dans Jenkins 2.3.

Dans la configuration de votre tâche, cliquez sur « Cette version est paramétrée »
et ajoutez les paramètres que vous souhaitez utiliser. Voir la liste des variables
définies pour les options - vos noms de paramètres doivent correspondre à ceux-
ci .e.g et dans l’exemple Groovy Script ci-dessous. Ensuite, après avoir installé
EnvInject, cliquez sur 'Préparer un environnement pour l’exécution' et
vérifiez :sourceBranchtargetBranch

Conserver les variables d’environnement Jenkins

Conserver les variables de build Jenkins
Remplacement des paramètres de build
Dans le champ Groovy Script, insérez quelque chose de similaire à :

def env = currentBuild.getEnvironment(currentListener)

def map = [:]

if (env.gitlabSourceBranch != null) {
map['sourceBranch'] = env.gitlabSourceBranch
}

if (env.gitlabTargetBranch != null) {
map['targetBranch'] = env.gitlabTargetBranch
}

return map
Vous pouvez ensuite référencer ces variables dans la configuration de votre tâche,
par exemple en tant que . Vous devrez mettre à jour ce code chaque fois que vous
ajouterez ou supprimerez des paramètres.${sourceBranch}

Remarque : Si vous utilisez Groovy Sandbox, vous devrez peut-être approuver le

script vous-même ou laisser un administrateur l’approuver dans la configuration
Jenkins.

Configuration de Git
Emplois freestyle
Dans la section Gestion du code source :

Cliquez sur Git

Entrez l’URL de votre référentiel, par exemple
[email protected]:gitlab_group/gitlab_project.git
Dans les paramètres avancés, définissez Name sur et Refspec sur
origin+refs/heads/*:refs/remotes/origin/*
+refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
Dans Spécificateur de branche, entrez :
Pour les flux de travail à référentiel unique : origin/${gitlabSourceBranch}
Pour les workflows de dépôt dupliqué : merge-requests/${gitlabMergeRequestIid}
Dans d’autres comportements :
Cliquez sur le bouton déroulant Ajouter
Sélectionnez Fusionner avant la génération dans la liste déroulante
Définissez le nom du référentiel sur origin
Définir la branche à fusionner en tant que ${gitlabTargetBranch}
Emplois dans les pipelines
Un bogue de Jenkins Pipeline empêchera le clone Git de fonctionner lorsque vous
utilisez un script Pipeline à partir de SCM. Cela fonctionne si vous utilisez
l’interface utilisateur de configuration de la tâche Jenkins pour modifier le
script. Il existe une solution de contournement mentionnée ici :
https://issues.jenkins-ci.org/browse/JENKINS-33719

Utilisez le générateur d’extraits, étape SCM générale, pour générer un exemple de

code Groovy pour le git checkout/merge, etc.

Exemple qui effectue la fusion avant la génération :

checkout changelog: true, poll: true, scm: [

$class: 'GitSCM',
 branches: [[name: "origin/${env.gitlabSourceBranch}"]],
extensions: [[$class: 'PreBuildMerge', options: [fastForwardMode: 'FF',
mergeRemote: 'origin', mergeStrategy: 'DEFAULT', mergeTarget: "$
{env.gitlabTargetBranch}"]]],
userRemoteConfigs: [[name: 'origin', url:
'[email protected]:foo/testrepo.git']]
]
Emplois Pipeline Multibranch
Note: Il n’existe aucun moyen de transmettre des données externes de GitLab à un
travail Pipeline Multibranch, de sorte que les variables d’environnement GitLab ne
sont pas renseignées pour ce type de travail. GitLab ne déclenchera que
l’indexation des branches pour le projet Jenkins, et Jenkins construira des
branches en conséquence sans avoir besoin, par exemple, de la branche git env var.
Pour cette raison, le plugin n’écoute que les Push Hooks GitLab pour les tâches de
pipeline multibranches ; les hooks de demande de fusion sont ignorés.

Cliquez sur Ajouter une source

Sélectionnez Git
Entrez l’URL de votre référentiel (par exemple :
[email protected]:group/repo_name.git)
Exemple de travaux de pipeline multibranches :Jenkinsfile

// Reference the GitLab connection name from your Jenkins Global configuration
(https://JENKINS_URL/configure, GitLab section)
properties([gitLabConnection('your-gitlab-connection-name')])

node {
checkout scm // Jenkins will clone the appropriate git branch, no env vars needed

// Further build steps happen here

}
Configuration du déclencheur de tâche
Webhook URL
Lorsque vous configurez le plugin pour déclencher votre job Jenkins, en suivant les
instructions ci-dessous en fonction du type de job, il écoutera sur une URL dédiée
pour les JSON POSTs depuis les webhooks de GitLab. Cette URL prend toujours la
forme , ou si le projet se trouve dans un dossier dans Jenkins. Vous ne devriez pas
utiliser ou , car cela contournerait complètement le
plugin.https://JENKINS_URL/project/PROJECT_NAMEhttps://JENKINS_URL/project/FOLDER/
PROJECT_NAMEhttps://JENKINS_URL/job/PROJECT_NAME/buildhttps://JENKINS_URL/job/
gitlab-plugin/buildWithParameters

Emplois Freestyle et Pipeline

Dans la section Déclencheurs de build :
Sélectionnez Générer lorsqu’une modification est poussée vers GitLab
Copiez l’URL du webhook GitLab affichée dans l’interface utilisateur (voir ici pour
plus d’informations)
Utilisez les cases à cocher pour déclencher des builds sur des événements Push
et/ou des événements de demande de fusion créés et/ou des événements de demande de
fusion acceptée et/ou des événements de demande de fusion fermée
Si vous le souhaitez, utilisez l’option Reconstruire les demandes de fusion
ouvertes pour permettre la reconstruction des demandes de fusion ouvertes après une
transmission vers la branche source
Si vous avez sélectionné Rebuild ouvrir les demandes de fusion autres que Aucune,
cochez Commentaires et spécifiez le commentaire pour le déclenchement d’une build.
Une nouvelle build sera déclenchée lorsque cette phrase apparaîtra dans un
commentaire de commit. En plus d’une phrase littérale, vous pouvez également
spécifier une expression régulière Java
Vous pouvez utiliser Générer sur des événements de pipeline réussis pour déclencher
une exécution réussie du pipeline dans GitLab. Notez que ce déclencheur de build ne
déclenchera un build que si le commit n’est pas déjà généré et ne définit pas le
statut GitLab. Sinon, vous risquez de vous retrouver dans une boucle
Configurez toute autre action de pré-build, de build ou de post-build si nécessaire
Cliquez sur Enregistrer pour conserver vos modifications dans Jenkins
Créez un webhook dans les projets GitLab pertinents (consultez la documentation
GitLab pour obtenir des instructions à ce sujet) et utilisez l’URL que vous avez
copiée à partir de l’interface utilisateur de configuration de la tâche Jenkins.
Cela devrait ressembler à quelque chose comme
https://JENKINS_URL/project/yourbuildname
Emplois Pipeline Multibranch
Contrairement à d’autres types de tâches, aucun paramètre « Déclencheur » n’est
requis pour la configuration d’une tâche à plusieurs branches. il suffit de créer
un webhook dans GitLab pour les requêtes push qui pointe vers l’URL du webhook du
projet. Lorsque GitLab effectue un POST sur cette URL, il déclenche l’indexation
des branches pour le projet Jenkins, et Jenkins se charge du démarrage de toutes
les constructions nécessaires.

Si vous souhaitez configurer certaines des options de déclenchement, telles que la

fonctionnalité de jeton secret ou de saut de CI, vous pouvez utiliser une étape.
Par exemple:properties

// Define your secret project token here

def project_token = 'abcdefghijklmnopqrstuvwxyz0123456789ABCDEF'

// Reference the GitLab connection name from your Jenkins Global configuration
(https://JENKINS_URL/configure, GitLab section)
properties([
gitLabConnection('your-gitlab-connection-name'),
pipelineTriggers([
[
$class: 'GitLabPushTrigger',
branchFilterType: 'All',
triggerOnPush: true,
triggerOnMergeRequest: false,
triggerOpenMergeRequestOnPush: "never",
triggerOnNoteRequest: true,
noteRegex: "Jenkins please retry a build",
skipWorkInProgressMergeRequest: true,
secretToken: project_token,
ciSkip: false,
setBuildDescription: true,
addNoteOnMergeRequest: true,
addCiMessage: true,
addVoteOnMergeRequest: true,
acceptMergeRequestOnSuccess: false,
branchFilterType: "NameBasedFilter",
includeBranchesSpec: "release/qat",
excludeBranchesSpec: "",
triggerOnBranchDeleteRequest: true,
triggerOnlyIfNewCommitsPushed: false,
triggerOnPipelineEvent: false,
triggerOnAcceptedMergeRequest: true,
triggerOnClosedMergeRequest: false,
triggerOnApprovedMergeRequest: false,
labelsThatForcesBuildIfAdded: "",
branchFilterName: "",
sourceBranchRegex: "",
targetBranchRegex: '^(.*/)?main$',
 mergeRequestLabelFilterConfig: [
include: "",
exclude: ""
],
pendingBuildName: "jenkins",
cancelPendingBuildsOnUpdate: true
]
])
])
Travaux de pipeline multibranche avec Job DSL
Vous pouvez utiliser la fonctionnalité DSL dynamique de Job DSL pour configurer le
déclencheur de tâche. Voir
https://github.com/jenkinsci/gitlab-plugin/blob/master/src/main/java/com/
dabsquared/gitlabjenkins/GitLabPushTrigger.java pour les méthodes que vous pouvez
utiliser.

job('seed-job') {

description('Job that makes sure a service has a build pipeline available')

parameters {
// stringParam('gitlabSourceRepoURL', '', 'the git repository url, e.g.
[email protected]:kubernetes/cronjobs/cleanup-jenkins.git')
}

triggers {
gitlab {
// This line assumes you set the API_TOKEN as an env var before
starting Jenkins - not necessarily required
secretToken(System.getenv("API_TOKEN"))
triggerOnNoteRequest(false)
}
}

steps {
dsl {
text(new File('/usr/share/jenkins/ref/jobdsl/multibranch-
pipeline.groovy').getText('UTF-8'))
}
}
}
Configuration de l’état de la build
Vous pouvez éventuellement faire en sorte que vos tâches Jenkins renvoient leur
état de build à GitLab, où il sera affiché dans l’interface utilisateur de la
demande de validation ou de fusion, le cas échéant.

Emplois freestyle
Utilisez l’action post-génération « Publier l’état de build sur GitLab » pour
renvoyer l’état de build avec le nom de build donné à GitLab. L’état de build « En
attente » est envoyé lorsque la build est déclenchée, l’état « En cours d’exécution
» est envoyé au démarrage de la build et l’état « Succès » ou « Échec » est envoyé
une fois la build terminée.

Assurez-vous également d’avoir choisi l’instance GitLab appropriée dans le menu

déroulant « Connexion GitLab », si vous en avez plusieurs.

Tâches de pipeline scriptées ou déclaratives

NOTE: Si vous utilisez des bibliothèques globales Pipeline ou si vous clonez le
fichier Jenkins de votre projet à partir d’un dépôt différent de celui qui contient
le code source approprié, vous devez faire attention au moment où vous envoyez
l’état du projet. En bref, assurez-vous de placer votre étape ou d’autres étapes
similaires après l’étape SCM qui clone la source de votre projet. Sinon, vous
risquez d’obtenir des erreurs HTTP 400 ou de constater que l’état de la génération
est envoyé au mauvais dépôt.gitlabCommitStatus

Tâches de pipeline scriptées

Pour les travaux de pipeline, complétez vos étapes de génération par l’étape
suivante : gitlabCommitStatus
node() {
stage('Checkout') { checkout <your-scm-config> }

gitlabCommitStatus {
// The result of steps within this block is what will be sent to GitLab
sh 'mvn install'
}
}
Vous pouvez également utiliser l’étape permettant d’utiliser une valeur
personnalisée pour mettre à jour le statut de validation. Vous pouvez utiliser des
blocs try/catch ou une autre logique pour envoyer un état précis de la compilation
à GitLab. Les statuts valides sont définis par GitLab et documentés ici.
updateGitlabCommitStatus
node() {
stage('Checkout') { checkout <your-scm-config> }

updateGitlabCommitStatus name: 'build', state: 'pending'

// Build steps

updateGitlabCommitStatus name: 'build', state: 'success'

}
Ou vous pouvez marquer plusieurs étapes de construction comme en attente dans
GitLab, en utilisant l’étape : Remarque : Si vous placez le bloc à l’intérieur d’un
bloc de nœud, il ne se déclenchera pas tant qu’un nœud n’aura pas été alloué. Sur
un système occupé, ou sur un système où les nœuds sont alloués à la demande, il
peut y avoir un retard et le statut « en attente » n’est pas envoyé immédiatement à
GitLab. Si cela pose problème, vous pouvez déplacer le bloc pour envelopper le bloc
de nœud, puis l’état sera envoyé lorsque Jenkins commencera à essayer d’allouer un
nœud.gitlabBuilds
node() {
stage('Checkout') { checkout <your-scm-config> }

gitlabBuilds(builds: ["build", "test"]) {

stage("build") {
gitlabCommitStatus("build") {
// your build steps
}
}

stage("test") {
gitlabCommitStatus("test") {
// your test steps
}
}
}
}
gitlabBuildsgitlabBuilds
Tâches de pipeline déclaratif
L’exemple ci-dessous configure la connexion GitLab et les déclencheurs de tâche. Il
renvoie également l’état de build à GitLab.
REMARQUE : Vous devrez exécuter cette tâche manuellement une fois, afin que Jenkins
puisse lire et configurer la configuration du déclencheur. Sinon, les webhooks ne
parviendront pas à déclencher le travail.

pipeline {
agent any
post {
failure {
updateGitlabCommitStatus name: 'build', state: 'failed'
}
success {
updateGitlabCommitStatus name: 'build', state: 'success'
}
aborted {
updateGitlabCommitStatus name: 'build', state: 'canceled'
}
}
options {
gitLabConnection('your-gitlab-connection-name')
}
triggers {
gitlab(triggerOnPush: true, triggerOnMergeRequest: true, branchFilterType:
'All')
}
stages {
stage("build") {
steps {
updateGitlabCommitStatus name: 'build', state: 'running'
echo "hello world"
}
}
}
[...]
}
Si:

Vous utilisez l’option « Fusionner lorsque le pipeline réussit » pour les demandes
de fusion dans GitLab, et
Vos travaux de pipeline déclaratif comportent plus d’une étape, et
Vous utilisez une étape dans chaque étape pour envoyer le statut à
GitLab...gitlabCommitStatus
Alors: Vous devrez définir ces étapes dans un bloc. Sinon, lorsque et si la
première étape passe, GitLab fusionnera le changement. Par exemple, si vous avez
trois étapes nommées build, test et deploy :options

options {
gitLabConnection('your-gitlab-connection-name')
gitlabBuilds(builds: ['build', 'test', 'deploy'])
}
Si vous souhaitez configurer l’un des déclencheurs de travail facultatifs pris en
charge par le plug-in dans une build déclarative, utilisez un bloc. La liste
complète des options de déclenchement configurables est la suivante :triggers

triggers {
gitlab(
triggerOnPush: false,
triggerOnMergeRequest: true, triggerOpenMergeRequestOnPush: "never",
triggerOnNoteRequest: true,
 noteRegex: "Jenkins please retry a build",
skipWorkInProgressMergeRequest: true,
ciSkip: false,
setBuildDescription: true,
addNoteOnMergeRequest: true,
addCiMessage: true,
addVoteOnMergeRequest: true,
acceptMergeRequestOnSuccess: false,
branchFilterType: "NameBasedFilter",
includeBranchesSpec: "release/qat",
excludeBranchesSpec: "",
pendingBuildName: "Jenkins",
cancelPendingBuildsOnUpdate: false,
secretToken: "abcdefghijklmnopqrstuvwxyz0123456789ABCDEF",
triggerToBranchDeleteRequest: false,
triggerOnlyIfNewCommitsPushed: false,
triggerOnPipelineEvent: false,
triggerOnAcceptedMergeRequest: true,
triggerOnClosedMergeRequest: false,
triggerOnApprovedMergeRequest: false,
labelsThatForcesBuildIfAdded: "",
branchFilterName: "",
sourceBranchRegex: "",
targetBranchRegex: '^(.*/)?main$',
mergeRequestLabelFilterConfig: [include: "", exclude: ""]
)
}
État de génération en attente pour les pipelines
Pour envoyer l’état de build « En attente » à GitLab lorsque le pipeline est
déclenché, définissez un nom de build sur le champ « Nom de build en attente pour
le pipeline » dans la section Avancé de la configuration du déclencheur ou utilisez
l’option pendingBuildName dans la configuration du déclencheur GitLab dans le
pipeline déclaratif.

Tâches matricielles/multi-configurations
Ce plugin peut être utilisé avec des tâches Matrix/Multi-configuration avec le
plugin Flexible Publish qui vous permet d’exécuter des éditeurs une fois que toutes
les tâches Axis sont terminées. Configurez les actions de post-génération comme
suit :

Ajouter une action de publication flexible

Dans la section Publication flexible :
Ajouter une action conditionnelle
Dans la section Action conditionnelle :
Réglez Run ? sur Never
Sélectionner la condition d’agrégation de matrice
Réglez l’option Exécuter sur le parent ? sur Toujours
Ajouter des actions GitLab si nécessaire
Voir aussi
Commentaires de violation au plugin GitLab pour des exemples de pipeline et de
travail DSL.
Fonctionnalités avancées
Filtrage des branches
Les déclencheurs peuvent être filtrés en fonction du nom de la branche, c’est-à-
dire que la compilation ne sera autorisée que pour les branches sélectionnées. Sur
la page de configuration du projet, lorsque vous configurez le déclencheur GitLab,
vous pouvez choisir « Filtrer les branches par nom » ou « Filtrer les branches par
regex ». Le filtrage par nom prend des listes de noms de branches séparés par des
virgules à inclure et/ou à exclure du déclenchement d’une build. Le filtrage par
expression régulière prend une expression régulière Java à inclure et/ou à exclure.
Par exemple, pour exclure toutes les branches contenant le mot « fonctionnalité »,
vous pouvez utiliser l’expression régulière suivante : . Dans le même ordre
d’idées, l’expression régulière signifie que toutes les branches ne correspondent
pas à master. Il s’agit d’une expression régulière qui utilise la prédiction
négative pour correspondre à toute chaîne qui ne contient pas le mot « master ».
Voici un aperçu de son fonctionnement :^(?:(?!feature).)*$^(?!.*master).*$

^: Anchors the match to the beginning of the string.

(: Starts a group that will be used for the negative lookahead.
?!: Indicates a negative lookahead assertion - finds all that does not match.
.*: Matches any number of characters (except for a newline) zero or more times.
master: should not match master.
): Ends the group.
$: Anchors the match to the end of the string.
Gardez à l’esprit que la fonctionnalité est sensible à la casse par défaut. Si vous
souhaitez qu’il ne soit pas sensible à la casse, vous pouvez utiliser l’indicateur
au début de votre modèle d’expression régulière. Par exemple:.RegexBasedFilter(?
i)^(?i)(?:(?!feature).)*$

Voici un exemple de script de pipeline qui montre comment utiliser la

fonctionnalité dans le déclencheur GitLab :RegexBasedFilter

triggers {
gitlab(
triggerOnPush: true,
triggerOnMergeRequest: false,
branchFilterType: "RegexBasedFilter",
targetBranchRegex: '^(?:(?!feature).)*$'
)
}
Note: Cette fonctionnalité nécessite l’accès à GitLab et une URL de dépôt git déjà
enregistrée dans la configuration du projet. En d’autres termes, lors de la
création d’un nouveau projet, la configuration doit être sauvegardée une fois avant
de pouvoir ajouter des filtres de branche. Pour les travaux de pipeline, la
configuration doit être enregistrée et le travail doit être exécuté une fois avant
que la liste ne soit remplie.

Construire lorsque les balises sont poussées

Pour construire lorsqu’une nouvelle balise est poussée :

Dans la configuration du webhook GitLab, ajoutez « Événements de push de balise »

Dans la configuration de la tâche sous 'Gestion du code source' :
Sélectionnez « Avancé... et ajoutez '' comme
Refspec+refs/tags/*:refs/remotes/origin/tags/*
Vous pouvez également utiliser 'Branch Specifier' pour spécifier quelle balise doit
être construite (exemple 'refs/tags/${TAGNAME}')
Ajouter une note aux demandes de fusion
Pour ajouter une note aux demandes de fusion GitLab une fois la génération
terminée, sélectionnez « Ajouter une note avec l’état de la génération sur les
demandes de fusion GitLab » à partir des actions facultatives de post-génération.
Si vous le souhaitez, cliquez sur le bouton « Avancé » pour personnaliser le
contenu de la note en fonction du résultat de la génération.

Tâches de pipeline - addGitLabMRComment

addGitLabMRComment(comment: 'The pipeline was run on Jenkins')
Notez qu’il nécessite que la build soit déclenchée par le webhook GitLab MR, et non
par le webhook push (ou la construction manuelle). Notez également qu’il ne
fonctionne actuellement pas avec les travaux Multibranch Pipeline, car les hooks MR
ne se déclenchent pas.

Accepter la demande de fusion

Pour accepter une demande de fusion une fois la génération terminée, sélectionnez «
Accepter la demande de fusion GitLab en cas de réussite » dans les actions
facultatives de post-génération.

Emplois dans les pipelines

Pour les tâches de pipeline, deux options de configuration avancées peuvent être
fournies

useMRDescription - Ajoute la description de la demande de fusion dans le commit de

fusion, dans un format similaire à celui qui serait reçu en sélectionnant 'Modifier
le message de validation' suivi de 'Inclure la description dans le message de
validation' dans l’interface utilisateur GitLab
removeSourceBranch - Supprime la branche source dans GitLab lorsque la demande de
fusion est acceptée
acceptGitLabMR(useMRDescription: true, removeSourceBranch: true)
Notifier un projet spécifique par une connexion GitLab spécifique
Vous pouvez spécifier une carte des builds de projet pour notifier une variété de
dépôts GitLab qui peuvent être situés sur différents serveurs. C’est utile si vous
souhaitez créer un CI/CD complexe qui implique plusieurs projets Jenkins et GitLab,
voir les exemples ci-dessous :

Notifier plusieurs projets GitLab à l’aide des données de connexion GitLab du

contexte de déclenchement :
gitlabCommitStatus(name: 'stage1',
builds: [
[projectId: 'test/test', revisionHash: 'master'],
[projectId: 'test/utils', revisionHash: 'master'],
])
{
echo 'Hello World'
}
Notifier plusieurs projets GitLab à l’aide d’une connexion GitLab spécifique :
gitlabCommitStatus( name: 'stage1', connection:gitLabConnection('site1-
connection'),
builds: [
[projectId: 'test/test', revisionHash: 'master'],
[projectId: 'test/utils', revisionHash: 'master'],
])
{
echo 'Hello World'
}
Notifier plusieurs dépôts GitLab situés sur différents serveurs GitLab :
gitlabCommitStatus(
builds: [
[name:'stage1',connection:gitLabConnection('site1-connection'),
projectId: 'group/project1', revisionHash: 'master'],
[name:'stage1',connection:gitLabConnection('site2-connection'),
projectId: 'group/project1', revisionHash: 'master'],
[name:'stage1',connection:gitLabConnection('site2-connection'),
projectId: 'test/test', revisionHash: 'master'],
[name:'stage1',connection:gitLabConnection('site2-connection'),
projectId: 'test/utils', revisionHash: 'master'],
])
{
echo 'Hello World'
}
Annuler les builds en attente lors de la mise à jour de la demande de fusion
Pour annuler les builds en attente de la même demande de fusion lorsque de
nouvelles validations sont envoyées, cochez la case « Annuler les builds de demande
de fusion en attente lors de la mise à jour » dans la section Avancé de la
configuration du déclencheur. Cela permet de gagner du temps dans les projets où
les builds peuvent rester longtemps dans une file d’attente de build et où vous ne
vous souciez que du statut du commit le plus récent.

Vérifier si un libellé est appliqué à une demande de fusion

Pour gérer la logique conditionnelle dans vos pipelines en fonction des étiquettes
de demande de fusion, utilisez les éléments suivants :

script {
if (GitLabMergeRequestLabelExists("bugfix"))
{
echo 'bugfix label detected!'
}
}
Une chaîne d’étiquettes séparée par des virgules est également présente en tant que
variable d’environnement : .
Par exemple pour une demande de fusion avec les libellés :
[, ], .gitlabMergeRequestLabelsbugfixreview
neededenv.gitlabMergeRequestLabels="bugfix,review needed"

Notes:
La variable d’environnement sera nulle si aucune étiquette n’est appliquée à la
demande de fusion.
Cette fonctionnalité n’est pas disponible pour les travaux de pipeline
multibranches ou les hooks GitLab.
Compatibilité
La version 1.2.1 du plugin introduit un changement incompatible avec les versions
antérieures pour les tâches Pipeline. Ils devront être reconfigurés manuellement
lorsque vous Passez à cette version. Les emplois de freestyle ne sont pas affectés.

Contribuer au plugin