Aller au contenu principal

Les règles de conditions de Gitlab CI/CD

· 3 minutes de lecture
Stéphane ROBERT

Les rules, règles, viennent remplacer only/except dans les fichiers de CI de gitlab. Cela permet d'étendre les conditions à d'autres variables et d'en simplifier l'écriture.

Utilisation d'une condition​

Il est possible de conditionner l'exécution d'un job à par exemple au nom de la branche. Il est possible d'étendre les conditions à d'autres variables en utilisant && et ||. On peut aussi tester ses propres variables.

Exemple : une regex sur le message de commit et le nom de la branche

jobone:
  script: echo "Hello World"
  rules:
    - if: '$CI_COMMIT_MESSAGE =~ /my_commit_message/ && $CI_COMMIT_BRANCH == "master"'

Limiter aux changements de certains fichiers​

On peut limiter le déclenchement d'un job à la modification ou la création de certains fichiers du référentiel.

Par exemple sur la modification de fichiers markdown ou restructuredtext.

jobone:
  script: echo "Hello World"
  rules:
    - if: $CI_COMMIT_BRANCH == "master" && $CI_PIPELINE_SOURCE != "schedule"
      changes:
        - source/*.md
        - source/*.rst

Limiter à la présence de certains fichiers​

On peut aussi limiter le déclenchement d'un job à la présence d'un ou plusieurs fichiers dans le référentiel. Pour cela on utilise exist qui accepte un tableau de chemins.

jobone:
  script: echo "Hello World"
  rules:
      - changes:
        - package.json
        - yarn.lock
      - exists:
        - node_modules

Conditionner le lancement des jobs à des événements​

On peut aussi définir des règles pour lancer des jobs en cas d'échec, manuellement, qu'en cas de succès, en le décalant dans le temps, ou pour inverser une condition.

On utilise le mot when qui s'accompagne d'une des valeurs suivantes :

  • on_success - Exécute le job uniquement lorsque tous les travaux des étapes précédentes réussissent ou sont considérés comme réussis via l'utilisation allow_failure: true.
  • on_failure - Exécuter la tâche uniquement lorsque au moins une tâche à une étape antérieure échoue.
  • always - Exécuter le job quel que soit le statut des travaux aux étapes précédentes.
  • manual- Lancement du job manuellement.
  • delayed- Retarder l'exécution d'un job pendant une durée spécifiée.
  • never - Ne lance pas le job dans ce cas

Exemple :

deploy_dev:
  script:
    - '& cd WebClient'
    - 'npm rebuild node-sass'
    - 'npm install @angular/cli@7.0.3'
    - '& npm run build-release --max_old_space_size=$NODE_MEMORY_SIZE'

  rules:
    - if: '$CI_COMMIT_REF_NAME== "development"'
      changes:
      - WebClient/**/*
      when: always

Des règles sur le pipeline​

Il est possible de définir des règles pour limiter l'exécution d'un pipeline au complet. Pour cela il suffit d'utiliser ce chemin workflow:rules

Par exemple ce pipeline se déclenche dans tous les cas, mais si le nom de la branche contient master ou feature certaines variables sont créées ou écrasées (si elles étaient définies auparavant) : DEPLOY_VARIABLES ou IS_A_FEATURE.

workflow:
  rules:
    - if: $CI_COMMIT_REF_NAME =~ /master/
      variables:
        DEPLOY_VARIABLE: "deploy-production"
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
    - when: always