Loading search data...

Gitlab - Utiliser des rules pour conditionner vos CI

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 lorsqu’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’éxé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

Alimenter un blog comme celui-ci est aussi passionnant que chronophage. En passant votre prochaine commande (n'importe quel autre article) via ce lien, je receverai une petite commission sans que cela ne vous coûte plus cher. Cela ne me permet pas de gagner ma vie, mais de couvrir les frais inhérents au fonctionnement du site. Merci donc à vous!

Mots clés :

devops, tutorials, gitlab, ci-cd,

Autres Articles