Skip to content

Latest commit

 

History

History
237 lines (194 loc) · 6.06 KB

06.Rules.md

File metadata and controls

237 lines (194 loc) · 6.06 KB
Raw

Contrôle d'exécution avec rules

Documentation GitLab : rules (L'utilisation des moits clés only, except sont dépréciés)

Le mots-clé rules est utilisé pour contrôler l'exécution des jobs.

Il accepte, un array avec les mots clés suivants :

  • if
  • changes
  • exists
  • allow_failure
  • variables
  • when

Avec des variables

Tout dabord, il faut créer le variable dans settings> CI CD > Variables Par exemple VAR:1234.

job:
  tags:
    - shell
  rules:
    - if: $VAR == "test"
  script:
    - echo "Ne s'éxecute quand quand la condition est remplie."

Et ensuite on lancer un pipeline sans modifier la variable.

La runner ne lance pas car la condition n'est pas remplie. Mais si l'on modifie la variable, cette fois le runner se lancera.

Cela fonctionne également avec les variables inclues de gitlab

job:
  script:
    - echo "Cette étape s'exécute si la condition est satisfaite"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Dans cet exemple, le job sera exécuté uniquement si la branche du commit est "main".

job:
  script:
    - echo "Cette étape s'exécute si le commit est tagué"
  rules:
    - if: '$CI_COMMIT_TAG'

Ici, le job sera exécuté uniquement si le commit est associé à un tag.

Rules avec la condition when

on_success

job:
  script:
    - echo "Cette étape s'exécute si les jobs précédents ont réussi"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: on_success

Dans cet exemple, le job sera exécuté uniquement si la branche du commit est "main" et si tous les jobs précédents dans le pipeline ont été exécutés avec succès.

manual

job:
  script:
    - echo "Cette étape s'exécute lorsque déclenchée manuellement"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual

Dans cet exemple, le job ne s'exécute que lorsque l'utilisateur le déclenche manuellement, indépendamment des autres de la réussite des autres jobs.

delayed

job:
  script:
    - echo "Cette étape s'exécute après un délai de 30 minutes"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: delayed
      start_in: 30 minutes

Ici, le job s'exécute automatiquement, mais il est retardé de 30 minutes à partir du déclenchement du pipeline.

scheduled

job:
  script:
    - echo "Cette étape s'exécute à une heure et une date spécifiques"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: scheduled
      cron: "0 12 * * *"

Dans cet exemple, le job est planifié pour s'exécuter tous les jours à midi.

Exercice

  • Créer un job nommé job_failure qui se déclenche uniquement si un des jobs précédent à échouer et que la branche du commit soit "main"
  • Créer un job nommé job_scan sera toujours exécuté, quelle que soit la réussite ou l'échec des jobs précédents, tant que la branche du commit est "main"

Réponse on_failure

job_failure:
  script:
    - echo "Cette étape s'exécute si les jobs précédents ont échoué"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: on_failure

Ce job s'exécutera uniquement si la branche du commit est "main" et si au moins l'un des jobs précédents dans le pipeline a échoué.

Réponse always

job_scan:
  script:
    - echo "Cette étape s'exécute toujours, quels que soient les résultats précédents"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: always

Ici, le job sera toujours exécuté, quelle que soit la réussite ou l'échec des jobs précédents, tant que la branche du commit est "main".

Les Conditions sur des Fichiers

change

La condition change vous permet de spécifier des fichiers ou des répertoires qui, lorsqu'ils sont modifiés dans un commit, autorise l'exécution d'un job. Cela peut être utile pour des tâches telles que la compilation du code uniquement lorsqu'un fichier source est modifié.

Voici un exemple :

job:
  script:
    - echo "Cette étape s'exécute si le fichier 'config.yaml' est modifié"
  rules:
    - changes:
        - config.yaml

Dans cet exemple, le job sera exécuté uniquement si le fichier config.yaml est modifié dans le commit actuel.

Exercice: Reprennez le pipeline parent-child, et rajouter les règles suivantes.

  • S'il y a des modifications dans le dossier ui, alors le pipeline ui s'executera
  • S'il y a des modifications dans le dossier backend, alors le pipeline backend se déclenche

Réponse :

trigger-ui:
  trigger:
    include: ui/.gitlab-ci.yml
    strategy: depend
  rules:
    - changes: [ui/*]
trigger-backend:
  trigger:
    include: backend/.gitlab-ci.yml
    strategy: depend
  rules:
    - changes: [backend/*]

exist

La condition exist vous permet de vérifier l'existence d'un fichier ou d'un répertoire dans le référentiel. Si le fichier ou le répertoire existe, le job est exécuté.

Voici un exemple :

job:
  script:
    - echo "Cette étape s'exécute si le fichier 'data.csv' existe"
  rules:
    - exists:
        - data.csv

Dans cet exemple, le job sera exécuté uniquement si le fichier data.csv existe dans le référentiel

Exercice

Créer un job qui s'éxecute uniquement si le fichier config.yamlest modifié et que le fichier .env existe.

Réponse

job:
  script:
    - echo "Cette étape s'exécute si 'config.yaml' est modifié et '.env' existe"
  rules:
    - changes:
        - config.yaml
    - exists:
        - .env

Les workflows

La directive workflow permet de contrôler le déclenchement de l'ensemble du pipeline basé sur des conditions, contrairement aux règles appliquées à des jobs individuels.

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "push"'
    - if: '$CI_COMMIT_BRANCH == "main"'

Dans cet exemple, le pipeline est déclenché si le déclencheur est un push sur la branche principale (main).