CI/CD GitLab CI pour rôle Ansible : pipeline parallel:matrix

Pipeline GitLab CI équivalent au workflow GitHub Actions — pour les équipes hébergées sur GitLab self-hosted ou gitlab.com. Stages : lint → test (parallel:matrix multi-distros × multi-versions). Release sur tag Git.

Ce que vous allez apprendre

Structure d’un .gitlab-ci.yml pour rôle Ansible.
parallel:matrix GitLab pour multi-distros × multi-versions.
needs: entre stages pour fail-fast.
rules: pour limiter les déclencheurs (MR, branche main, tags).
Job de release automatique sur tag Git.

Le pipeline `.gitlab-ci.yml`

---
stages:
  - lint
  - test

variables:
  PIP_DISABLE_PIP_VERSION_CHECK: "1"
  PIP_NO_CACHE_DIR: "1"
  PY_COLORS: "1"
  ANSIBLE_FORCE_COLOR: "1"

default:
  image: python:3.12-slim
  tags:
    - docker

# ─── Lint ───
ansible-lint:
  stage: lint
  before_script:
    - pip install ansible-lint==25.* yamllint
  script:
    - yamllint roles/
    - ansible-lint --profile=production roles/
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

# ─── Test multi-distros via matrice ───
molecule-test:
  stage: test
  needs: ["ansible-lint"]
  parallel:
    matrix:
      - DISTRO: rockylinux9
        ANSIBLE_VERSION: "2.17"
      - DISTRO: rockylinux9
        ANSIBLE_VERSION: "2.18"
      - DISTRO: alma10
        ANSIBLE_VERSION: "2.18"
      - DISTRO: ubuntu2404
        ANSIBLE_VERSION: "2.18"
  before_script:
    - apt-get update && apt-get install -y --no-install-recommends podman
    - pip install
        "ansible-core==${ANSIBLE_VERSION}.*"
        "molecule>=26.0"
        "molecule-plugins[podman]>=25.0"
    - ansible-galaxy collection install -r requirements.yml
  script:
    - molecule test
  variables:
    MOLECULE_DISTRO: $DISTRO

# ─── Job de release sur tag Git ───
release:
  stage: test
  needs: ["molecule-test"]
  script:
    - echo "Release du rôle webserver vers Galaxy ici"
    # ansible-galaxy role import via API token chiffré dans GitLab CI Variables
  rules:
    - if: $CI_COMMIT_TAG

Décortication

`stages:` — ordre d’exécution

stages:
  - lint
  - test

Lint avant test = fail-fast.

`default:` — config commune

default:
  image: python:3.12-slim
  tags:
    - docker

Image Python officielle, runners taggés docker (à adapter selon vos GitLab runners).

`parallel:matrix` — la matrice GitLab

molecule-test:
  parallel:
    matrix:
      - DISTRO: rockylinux9
        ANSIBLE_VERSION: "2.17"
      - DISTRO: rockylinux9
        ANSIBLE_VERSION: "2.18"
      - DISTRO: alma10
        ANSIBLE_VERSION: "2.18"

Différence avec GitHub Actions : la matrice GitLab est explicite (chaque combinaison listée). Plus verbeux, mais plus contrôlable — vous pouvez exclure des combinaisons facilement (pas besoin d’exclude:).

`needs:` entre stages

molecule-test:
  needs: ["ansible-lint"]

molecule-test ne démarre que si ansible-lint a réussi. Sans needs, GitLab respecte juste l’ordre de stages: mais lance tous les jobs du stage simultanément — needs: permet le DAG (Directed Acyclic Graph) plus précis.

`rules:` pour limiter les déclencheurs

ansible-lint:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

Le job ne tourne que sur :

les merge requests (équivalent pull requests GitHub).
les commits sur main (post-merge).

Pas sur les autres branches → économie CI minutes.

Release sur tag Git

release:
  rules:
    - if: $CI_COMMIT_TAG

Le job ne tourne que quand un tag Git est créé (git tag -a v1.0.0). Workflow recommandé : tag depuis main → release automatique sur Galaxy.

Variables CI/CD GitLab utilisées

Variable	Description
`$CI_COMMIT_TAG`	Tag Git si déclencheur tag, vide sinon
`$CI_COMMIT_BRANCH`	Branche du commit
`$CI_PIPELINE_SOURCE`	Source du pipeline (`push`, `merge_request_event`, `schedule`…)
`$DISTRO`, `$ANSIBLE_VERSION`	Variables de matrice (custom, définies dans `parallel:matrix`)

Tokens chiffrés pour la release

Le job release a besoin du token API Galaxy pour publier. Jamais en clair — utiliser les CI/CD Variables GitLab :

Repo → Settings → CI/CD → Variables.
Ajouter GALAXY_TOKEN avec Masked + Protected.

Dans le job release :

release:
  script:
    - ansible-galaxy role import --api-key=$GALAXY_TOKEN ...

Masked = token absent des logs CI. Protected = utilisable seulement sur branches/tags protégés (main, v*).

Comparaison GitHub Actions vs GitLab CI

Aspect	GitHub Actions	GitLab CI
Matrice	`strategy.matrix:` (auto-combinaisons)	`parallel:matrix:` (explicite)
DAG entre jobs	`needs:`	`needs:`
Cache	`actions/cache@v4`	Native (`cache:`)
Secrets	Repo settings → Secrets	Settings → CI/CD → Variables
Schedule	`on.schedule.cron`	Pipeline schedules (UI)
Self-hosted runners	Runners	Runners (`tags:`)

Conclusion : les deux fonctionnent — GitLab CI est plus explicite, GitHub Actions plus concis. Choisir selon votre hébergement de code.

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/ci/gitlab/ dans stephrobert/ansible-training.

Le lab fournit .gitlab-ci.yml complet. 7 tests structure validés (stages, matrix, needs, rules, release).

cd ~/Projets/ansible-training/labs/ci/gitlab/

cat .gitlab-ci.yml
pytest -v challenge/tests/             # 7 tests structure

Pièges courants

Symptôme	Cause	Fix
Job ne se déclenche pas	`rules:` mal écrit	Tester avec `ci-lint` GitLab
`parallel:matrix` plante	Quote string vs int	`ANSIBLE_VERSION: "2.17"` (avec quotes)
Token Galaxy en clair dans logs	Pas configuré `Masked`	CI/CD Variables → Edit → cocher `Masked`
Runner non dispo	`tags: [docker]` mais pas de runner avec ce tag	Vérifier les runners disponibles + adapter tags
`apt-get` lent	`image: python:3.12-slim` recharge à chaque job	Custom image avec deps pré-installées

À retenir

GitLab CI = équivalent GitHub Actions pour les équipes auto-hébergées.
parallel:matrix: explicite > strategy.matrix.exclude: GitHub.
needs: entre stages = DAG précis.
rules: if pour limiter les déclencheurs (MR, main, tags).
CI/CD Variables Masked + Protected pour les tokens.

Prochaines étapes

Intégration GitHub Actions Workflow équivalent côté GitHub si vous hébergez là-bas

Versionner et publier Le job release qui tag → publish Galaxy automatiquement

ansible-lint production Le linter strict appelé en premier dans le pipeline

Tests tox multi-versions tox appelé depuis GitLab CI — orchestration locale équivalente