Utilisation de l'Axe DevTools Linter avec Bitbucket Pipelines

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

Comment configurer une étape de Bitbucket Pipelines pour vérifier le code à la recherche de problèmes d'accessibilité à l'aide d'Axe DevTools Linter

Free Trial
Not for use with personal data

Vous pouvez soumettre votre code à l'Axe DevTools Linter pour être vérifié pour des problèmes d'accessibilité dans le cadre d'une construction de Bitbucket Pipelines. Contrairement à GitHub, il n'y a pas de pipe Bitbucket dédié pour Axe DevTools Linter, donc ce guide montre comment invoquer le Connecteur Axe DevTools Linter directement en tant qu'étape dans votre bitbucket-pipelines.yml.

Exigences

  • Un dépôt Bitbucket avec Pipelines activés.
  • Node.js et npm disponibles dans l'image du pipeline (l'image par défaut de Bitbucket Pipelines inclut les deux) pour pouvoir installer le Connecteur avec npm. Voir Installation du Connecteur Axe DevTools Linter en tant que package npm.
  • Une clé API ou une clé de licence pour autoriser le Connecteur. Voir Choisir la bonne configuration pour savoir comment votre modèle de déploiement (SaaS, cloud privé ou sur site) détermine celle que vous utilisez.

Étape 1 : Ajouter une variable de dépôt pour votre clé

Ajoutez votre clé en tant que variable de dépôt sécurisée pour qu'elle ne soit pas exposée dans les journaux de votre pipeline. Accédez à la page paramètres du dépôt de votre dépôt, puis à variables du dépôt, et ajoutez l'une des options suivantes, marquée Sécurisé :

  • AXE_LINTER_API_KEY pour une clé API
  • AXE_LINTER_LICENSE_KEY pour une clé de licence

Pour plus d'informations, consultez la documentation de Bitbucket sur variables et secrets du dépôt.

Étape 2 : Ajouter une étape de pipeline

tip

Deque recommande le linting local (comme indiqué ci-dessous) pour Bitbucket Pipelines : c'est nettement plus rapide et, avec une clé de licence, cela évite également la question de savoir si les runners hébergés de Bitbucket peuvent atteindre votre serveur Axe DevTools Linter.

Ajoutez une étape à votre bitbucket-pipelines.yml qui installe le Connecteur et l'exécute avec l'option --local. Le linting local analyse vos fichiers sur le runner du pipeline lui-même au lieu de les envoyer à un serveur, de sorte qu'il fonctionne de la même manière, que votre déploiement soit SaaS, cloud privé ou sur site.

Avec une clé de licence

Utiliser une clé de licence signifie que le Connecteur n'effectue aucun appel réseau du tout :

image: node:20

pipelines:
  default:
    - step:
        name: Lint for accessibility issues
        script:
          - npm install -g @axe-devtools/axe-linter-connector
          - axe-linter-connector -s . -d . --license-key $AXE_LINTER_LICENSE_KEY --local

Avec une clé API

L'utilisation d'une clé API nécessite toujours que le Connecteur atteigne un serveur d'authentification pour valider la clé et enregistrer l'utilisation, même avec --local :

image: node:20

pipelines:
  default:
    - step:
        name: Lint for accessibility issues
        script:
          - npm install -g @axe-devtools/axe-linter-connector
          - axe-linter-connector -s . -d . --api-key $AXE_LINTER_API_KEY --local

Pour Axe DevTools Linter SaaS, le serveur d'authentification par défaut (https://axe.deque.com) est utilisé automatiquement. Les clients cloud privés doivent définir la variable d'environnement AXE_SERVICE_URL à l'URL d'authentification de leur instance cloud privée avant d'exécuter le Connecteur.

Linting basé sur le serveur (Alternative)

Si vous ne souhaitez pas faire de linting local, vous pouvez envoyer les fichiers à un serveur Axe DevTools Linter en omettant --local et en spécifiant --url. Le serveur auquel vous pouvez accéder dépend de votre modèle de déploiement :

  • SaaS : les runners hébergés de Bitbucket peuvent atteindre le serveur SaaS de Deque sans configuration supplémentaire, car il est déjà accessible sur internet.
  • Sur site : n'exposez pas votre serveur sur site à internet juste pour que les runners hébergés de Bitbucket puissent l'atteindre. Au lieu de cela, utilisez un runner auto-hébergé de Bitbucket afin que votre étape de pipeline soit exécutée à l'intérieur de votre propre réseau, de la même manière que votre serveur sur site est atteint par d'autres outils internes.

Résultats de l'étape de pipeline

Le Connecteur écrit un rapport d'accessibilité dans le répertoire de destination (axe-linter-report.json par défaut), contenant les erreurs d'accessibilité spécifiques trouvées, y compris le nom du fichier et le numéro de ligne. Les violations d'accessibilité en elles-mêmes ne changent pas le code de sortie du Connecteur ni n'échouent l'étape Bitbucket. Le Connecteur ne sort un code non nul que pour un problème avec le scan lui-même, tel qu'une option manquante, un serveur inatteignable ou une clé rejetée. Voir Codes de sortie pour la liste complète.

note

Si vous voulez que l'étape du pipeline échoue lorsqu'une violation d'accessibilité est trouvée, ajoutez une étape de script qui inspecte le rapport généré et sort un code non nul, similaire au script de build montré dans Utiliser Axe DevTools Linter avec Jenkins.

Étapes suivantes

Pour des informations sur les règles utilisées par Axe DevTools Linter pour vérifier votre code, consultez Règles d'accessibilité. Si vous souhaitez intégrer le rapport dans SonarQube, consultez Utiliser Axe DevTools Linter avec SonarQube.