GitLab CI

Contrôlez l’accessibilité dans chaque merge request

Utilisez le même contrat wcagc dans GitLab CI : testez les URL de prévisualisation, comparez les constats à une référence et obtenez un verdict de pipeline explicite.

Créer une clé API

Ajouter le modèle de pipeline

Stockez la clé API et les URL comme variables CI/CD, puis ajoutez les jobs réutilisables. Les merge requests comparent seulement ; la branche par défaut met à jour la référence.

.wcagc-check:
  image: node:24-alpine
  script:
    - npx --yes github:WCAG-Compliance/wcagc-ci#v1

wcagc-merge-request:
  extends: .wcagc-check
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

wcagc-default-branch-baseline:
  extends: .wcagc-check
  variables:
    WCAGC_FAIL_ON: none
    WCAGC_SET_BASELINE: "true"
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

Configurer les variables CI/CD

Gardez une configuration explicite et les identifiants hors du dépôt.

WCAGC_API_KEY
Secret masqué obligatoire avec les droits scans:read et scans:write. Ne l’exposez pas aux pipelines de forks non fiables.
WCAGC_URLS
URL enregistrées obligatoires, séparées par ligne ou virgule, avec un maximum de 20 par contrôle.
WCAGC_FAIL_ON
Utilisez new-critical par défaut, ou any-critical, serious-or-worse ou none.
WCAGC_SET_BASELINE
Activez uniquement dans le job protégé de la branche par défaut afin qu’un pipeline de revue ne puisse pas modifier la référence.

Un pipeline de merge request est une frontière de confiance

Les variables GitLab protégées ne sont accessibles qu’aux refs protégées éligibles, sauf assouplissement explicite. Vérifiez les paramètres des forks et variables avant les contributions externes.

Une sortie claire et des codes prévisibles

La CLI affiche les sévérités, nouveaux constats, lien du rapport et limite de l’automatisation. PASS renvoie 0, un contrôle échoué ou une erreur d’exécution 1, et une configuration invalide 2.