doc-locale/fr-fr/ci/jobs/_index.md
{{< details >}}
{{< /details >}}
Les jobs CI/CD sont les éléments fondamentaux d'un pipeline CI/CD GitLab. Les jobs sont configurés dans le fichier .gitlab-ci.yml avec une liste de commandes à exécuter pour accomplir des tâches telles que la compilation, les tests ou le déploiement de code.
Jobs :
Les jobs sont définis avec des mots-clés YAML qui définissent tous les aspects de l'exécution du job, notamment les mots-clés qui :
Pour ajouter un job à un pipeline, ajoutez-le dans votre fichier .gitlab-ci.yml. Le job doit :
script définissant les commandes à exécuter, soit une section trigger pour déclencher un pipeline downstream.Par exemple :
my-ruby-job:
script:
- bundle install
- bundle exec my_ruby_command
my-shell-script-job:
script:
- my_shell_script.sh
Vous ne pouvez pas utiliser ces mots-clés comme noms de jobs :
imageservicesstagesbefore_scriptafter_scriptvariablescacheincludepages:deploy configuré pour une étape deployDe plus, ces noms sont valides lorsqu'ils sont entre guillemets, mais ne sont pas recommandés car ils peuvent rendre la configuration du pipeline peu claire :
"true":"false":"nil":Les noms de jobs doivent comporter 255 caractères ou moins.
Utilisez des noms uniques pour vos jobs. Si plusieurs jobs portent le même nom dans un fichier, un seul est ajouté au pipeline et il est difficile de prédire lequel sera choisi. Si le même nom de job est utilisé dans un ou plusieurs fichiers inclus, les paramètres sont fusionnés.
Pour désactiver temporairement un job sans le supprimer du fichier de configuration, ajoutez un point (.) au début du nom du job. Les jobs masqués n'ont pas besoin de contenir les mots-clés script ou trigger, mais doivent contenir une configuration YAML valide.
Par exemple :
.hidden_job:
script:
- run test
Les jobs masqués ne sont pas traités par GitLab CI/CD, mais ils peuvent être utilisés comme modèles pour une configuration réutilisable avec :
Vous pouvez utiliser le mot-clé default pour définir des mots-clés et des valeurs de job par défaut, qui sont utilisés par défaut par tous les jobs d'un pipeline.
Par exemple :
default:
image: 'ruby:2.4'
before_script:
- echo Hello World
rspec-job:
script: bundle exec rspec
Lorsque le pipeline s'exécute, le job utilise les mots-clés par défaut :
rspec-job:
image: 'ruby:2.4'
before_script:
- echo Hello World
script: bundle exec rspec
Vous pouvez contrôler l'héritage de :
Par exemple :
default:
image: 'ruby:2.4'
before_script:
- echo Hello World
variables:
DOMAIN: example.com
WEBHOOK_URL: https://my-webhook.example.com
rubocop:
inherit:
default: false
variables: false
script: bundle exec rubocop
rspec:
inherit:
default: [image]
variables: [WEBHOOK_URL]
script: bundle exec rspec
capybara:
inherit:
variables: false
script: bundle exec capybara
karma:
inherit:
default: true
variables: [DOMAIN]
script: karma
Dans cet exemple :
rubocop :
rspec :
image et de la variable WEBHOOK_URL.before_script et de la variable DOMAIN.capybara :
before_script et de image.DOMAIN et WEBHOOK_URL.karma :
image et de before_script, et la variable DOMAIN.WEBHOOK_URL.Lorsque vous accédez à un pipeline, vous pouvez voir les jobs associés à ce pipeline.
L'ordre des jobs dans un pipeline dépend du type de graphe de pipeline.
La sélection d'un job individuel affiche son job log et vous permet de :
{{< details >}}
{{< /details >}}
{{< history >}}
populate_and_use_build_names_table pour l'API et fe_search_build_by_name pour l'interface utilisateur. Désactivé par défaut.populate_and_use_build_names_table et fe_search_build_by_name ont été supprimés.{{< /history >}}
Pour afficher les jobs exécutés dans un projet :
Vous pouvez filtrer la liste par statut de job, source, nom et type.
[!note] Le filtre par nom renvoie les jobs créés au cours des 30 derniers jours. Cette période de rétention s'applique au filtrage via l'interface utilisateur et via l'API.
Par défaut, le filtre affiche uniquement les jobs de build. Pour afficher les jobs déclencheurs, effacez le filtre, puis sélectionnez Type > Déclencheur.
[!note] Le filtre Type est disponible uniquement pour les jobs de projet. Il n'est pas disponible dans la zone Admin.
Les jobs CI/CD peuvent avoir les statuts suivants :
canceled : Le job a été annulé manuellement ou abandonné automatiquement.canceling : Le job est en cours d'annulation, mais after_script est en cours d'exécution.created : Le job a été créé mais n'a pas encore été traité.failed : L'exécution du job a échoué.manual : Le job nécessite une action manuelle pour démarrer.pending : Le job est en file d'attente en attente d'un runner.preparing : Le runner prépare l'environnement d'exécution.running : Le job s'exécute sur un runner.scheduled : Le job a été planifié mais l'exécution n'a pas encore commencé.skipped : Le job a été ignoré en raison de conditions ou de dépendances.success : Le job s'est terminé avec succès.waiting_for_callback : Le job attend un rappel d'un service externe.waiting_for_resource : Le job attend que des ressources deviennent disponibles.{{< history >}}
populate_and_use_build_source_table. Activé par défaut.{{< /history >}}
Les jobs GitLab CI/CD incluent un attribut source qui indique l'action qui a déclenché le job. Utilisez cet attribut pour suivre comment un job a été initié ou pour filtrer les exécutions de jobs en fonction de sources spécifiques.
L'attribut source peut avoir les valeurs suivantes :
api : Job initié par un appel REST à l'API Jobs.chat : Job initié par une commande de chat via GitLab ChatOps.container_registry_push : Job initié par un push vers le registre de conteneurs.duo_workflow : Job initié par GitLab Duo Agent Platform.external : Job initié par un événement dans un dépôt externe intégré à GitLab. Cela n'inclut pas les événements de pull request.external_pull_request_event : Job initié par un événement de pull request dans un dépôt externe.merge_request_event : Job initié par un événement de merge request.ondemand_dast_scan : Job initié par un scan DAST à la demande.ondemand_dast_validation : Job initié par une validation DAST à la demande.parent_pipeline : Job initié par un pipeline parentpipeline : Job initié par un utilisateur exécutant manuellement un pipeline.pipeline_execution_policy : Job initié par une politique d'exécution de pipeline.pipeline_execution_policy_schedule : Job initié par une politique d'exécution de pipeline planifiée.push : Job initié par un push de code.scan_execution_policy : Job initié par une politique d'exécution de scan.schedule : Job initié par un pipeline planifié.security_orchestration_policy : Job initié par une politique d'exécution de scan planifiée.trigger : Job initié par un autre job ou pipeline.unknown : Job initié par une source inconnue.web : Job initié par un utilisateur depuis l'interface utilisateur de GitLab.webide : Job initié par un utilisateur depuis le Web IDE.Si vous avez de nombreux jobs similaires, votre graphe de pipeline devient long et difficile à lire.
Vous pouvez regrouper automatiquement des jobs similaires. Si les noms de jobs sont formatés d'une certaine manière, ils sont réduits en un seul groupe dans les graphes de pipeline classiques (pas les mini-graphes).
Vous pouvez identifier qu'un pipeline contient des jobs groupés lorsque vous voyez un nombre à côté d'un nom de job au lieu des boutons de relance ou d'annulation. Le nombre indique la quantité de jobs groupés. En les survolant, vous pouvez voir si tous les jobs ont réussi ou si l'un d'eux a échoué. Sélectionnez pour les développer.
Pour créer un groupe de jobs, dans le fichier .gitlab-ci.yml, séparez chaque nom de job par un nombre et l'un des éléments suivants :
/ ou \), par exemple, slash-test 1/3, slash-test 2/3, slash-test 3/3.:), par exemple, colon-test 1:3, colon-test 2:3, colon-test 3:3.space-test 0 3, space-test 1 3, space-test 2 3.Vous pouvez utiliser ces symboles de manière interchangeable.
Dans l'exemple suivant, ces trois jobs sont dans un groupe nommé build ruby :
build ruby 1/3:
stage: build
script:
- echo "ruby1"
build ruby 2/3:
stage: build
script:
- echo "ruby2"
build ruby 3/3:
stage: build
script:
- echo "ruby3"
Le graphe de pipeline affiche un groupe nommé build ruby avec trois jobs.
Les jobs sont ordonnés en comparant les nombres de gauche à droite. En général, vous souhaitez que le premier nombre soit l'index et le second le total.
Vous pouvez relancer un job après son exécution, quel que soit son état final (échec, succès ou annulé).
Lorsque vous relancez un job :
Lorsque vous relancez un job déclencheur qui déclenche un pipeline downstream :
Prérequis :
Pour relancer un job depuis une merge request :
Pour relancer un job depuis le job log :
Pour relancer un job depuis un pipeline :
Si un pipeline contient plusieurs jobs en échec ou annulés, vous pouvez tous les relancer en même temps :
Vous pouvez annuler un job CI/CD qui n'est pas encore terminé. Lorsque vous annulez un job, ce qui se passe ensuite dépend de son état :
canceling.before_script ou script du job est ignoré.after_script, celle-ci démarre toujours et s'exécute jusqu'à la fin.canceled.Si vous devez annuler un job immédiatement sans attendre after_script, utilisez l'annulation forcée.
Prérequis :
Pour annuler un job depuis une merge request :
Pour annuler un job depuis le job log :
Pour annuler un job depuis un pipeline :
Vous pouvez annuler tous les jobs d'un pipeline en cours d'exécution en une seule fois.
{{< history >}}
force_cancel_build. Désactivé par défaut.force_cancel_build a été supprimé.{{< /history >}}
Si vous ne souhaitez pas attendre la fin de after_script ou si un job ne répond pas, vous pouvez forcer son annulation. L'annulation forcée fait passer immédiatement un job de l'état canceling à canceled.
Lorsque vous forcez l'annulation d'un job, le token de job est immédiatement révoqué. Si le runner est encore en train d'exécuter le job, il perd l'accès à GitLab. Le runner abandonne le job sans attendre la fin de after_script.
Prérequis :
canceling, ce qui nécessite :
Pour forcer l'annulation d'un job :
Lorsqu'un pipeline échoue ou est autorisé à échouer, il existe plusieurs endroits où vous pouvez trouver la raison :
À chaque endroit, si vous survolez le job en échec, vous pouvez voir la raison de son échec.
Vous pouvez également voir la raison de l'échec sur la page de détail du job.
Vous pouvez utiliser GitLab Duo Root Cause Analysis dans GitLab Duo Chat pour dépanner les jobs CI/CD en échec.
Les jobs de déploiement sont des jobs CI/CD qui utilisent des environnements. Un job de déploiement est tout job qui utilise le mot-clé environment et l'environnement start action. Les jobs de déploiement n'ont pas besoin d'être dans l'étape deploy. Le job deploy me suivant est un exemple de job de déploiement. action: start est le comportement par défaut et est défini ici pour plus de clarté, mais vous pouvez l'omettre :
deploy me:
script:
- deploy-to-cats.sh
environment:
name: production
url: https://cats.example.com
action: start
Le comportement des jobs de déploiement peut être contrôlé avec les paramètres de sécurité des déploiements, comme la prévention des jobs de déploiement obsolètes et la garantie qu'un seul job de déploiement s'exécute à la fois.