GitLab CI

Проверяйте доступность в каждом merge request

Используйте единый контракт wcagc в GitLab CI: проверяйте preview-URL, сравнивайте находки с базовой линией и получайте однозначный статус pipeline.

Создать API-ключ

Добавьте шаблон pipeline

Сохраните API-ключ и URL как CI/CD-переменные, затем подключите переиспользуемые jobs. Merge request только сравнивает результаты, а базовую линию обновляет основная ветка.

.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'

Настройте CI/CD-переменные

Храните конфигурацию явно, а учётные данные — вне репозитория.

  • WCAGC_API_KEY

    Обязательный masked-секрет с правами scans:read и scans:write. Не передавайте его pipeline из недоверенных форков.

  • WCAGC_URLS

    Обязательные зарегистрированные URL через новую строку или запятую, не более 20 на проверку.

  • WCAGC_FAIL_ON

    По умолчанию new-critical; также доступны any-critical, serious-or-worse и none.

  • WCAGC_SET_BASELINE

    Включайте только в защищённой job основной ветки, чтобы review-pipeline не мог переписать точку сравнения.

Считайте merge-request pipeline границей доверия

Защищённые переменные GitLab доступны только подходящим защищённым refs, если вы явно не ослабили политику. Проверьте настройки форков и protected variables до запуска внешних contributions.

Понятный вывод и предсказуемые коды завершения

CLI печатает уровни серьёзности, новые находки, ссылку на отчёт и ограничение автоматической проверки. PASS возвращает 0, провал проверки или ошибка выполнения — 1, неверная конфигурация — 2.