Verwendung von Axe DevTools Linter mit 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

Einrichtung eines Bitbucket Pipelines-Schritts zur Überprüfung von Code auf Barrierefreiheitsprobleme mit Axe DevTools Linter

Free Trial

Not for use with personal data

Sie können Ihren Code an Axe DevTools Linter übermitteln, um ihn auf Barrierefreiheitsprobleme im Rahmen eines Bitbucket Pipelines-Builds prüfen zu lassen. Im Gegensatz zu GitHub gibt es bei Bitbucket kein spezielles Pipe für Axe DevTools Linter, daher zeigt dieser Leitfaden, wie man den Axe DevTools Linter Connector direkt als Schritt in Ihren bitbucket-pipelines.yml aufruft.

Anforderungen

Ein Bitbucket-Repository mit aktivierten Pipelines.
Node.js und npm müssen im Pipeline-Image verfügbar sein (das Standard-Bitbucket Pipelines-Image enthält beide), damit der Connector mit npm installiert werden kann. Siehe Installation des Axe DevTools Linter Connector als npm-Paket.
Ein API-Schlüssel oder ein Lizenzschlüssel zur Autorisierung des Connectors. Siehe Die richtige Einrichtung wählen, um zu erfahren, wie Ihr Bereitstellungsmodell (SaaS, Private Cloud oder On-Premises) bestimmt, welchen Sie verwenden.

Schritt 1: Hinzufügen einer Repository-Variablen für Ihren Schlüssel

Fügen Sie Ihren Schlüssel als gesicherte Repository-Variable hinzu, damit er nicht in Ihren Pipeline-Protokollen angezeigt wird. Gehen Sie zu der Seite Repository-Einstellungen Ihres Repositorys, dann Repository-Variablen, und fügen Sie eines der folgenden, markiert mit Gesichert, hinzu:

AXE_LINTER_API_KEY für einen API-Schlüssel
AXE_LINTER_LICENSE_KEY für einen Lizenzschlüssel

Für weitere Informationen siehe Bitbuckets eigene Dokumentation zu Repository-Variablen und Geheimnisse.

Schritt 2: Hinzufügen eines Pipeline-Schritts

tip

Deque empfiehlt lokales Linting (wie unten gezeigt) für Bitbucket Pipelines: Es ist erheblich schneller und vermeidet bei Verwendung eines Lizenzschlüssels zudem die Frage, ob die von Bitbucket gehosteten Runner Ihren Axe DevTools Linter-Server überhaupt erreichen können.

Fügen Sie einen Schritt zu Ihrem bitbucket-pipelines.yml hinzu, der den Connector installiert und ihn mit der --local-Option ausführt. Lokales Linting analysiert Ihre Dateien auf dem eigenen Runner der Pipeline, anstatt sie an einen Server zu senden. So funktioniert es unabhängig davon, ob Ihre zugrunde liegende Bereitstellung SaaS, Private Cloud oder On-Premises ist.

Mit einem Lizenzschlüssel

Die Verwendung eines Lizenzschlüssels bedeutet, dass der Connector überhaupt keine Netzwerkanfragen stellt:

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

Mit einem API-Schlüssel

Die Verwendung eines API-Schlüssels erfordert dennoch, dass der Connector einen Authentifizierungsserver erreicht, um den Schlüssel zu validieren und die Nutzung zu protokollieren, selbst mit --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

Für Axe DevTools Linter SaaS wird der standardmäßige Authentifizierungsserver (https://axe.deque.com) automatisch verwendet. Private Cloud-Kunden müssen die AXE_SERVICE_URL-Umgebungsvariable auf die Authentifizierungs-URL ihrer Private Cloud-Instanz setzen, bevor sie den Connector ausführen.

Serverbasiertes Linting (Alternative)

Wenn Sie nicht lokal linten möchten, können Sie stattdessen Dateien an einen Axe DevTools Linter-Server senden, indem Sie --local weglassen und --url angeben. Welchen Server Sie erreichen können, hängt von Ihrem Bereitstellungsmodell ab:

SaaS: Die von Bitbucket gehosteten Runner können ohne zusätzliche Einrichtung direkt Deques SaaS-Server erreichen, da dieser bereits internetfähig ist.
On-Premises: Setzen Sie Ihren On-Prem-Server nicht dem Internet aus, nur damit die von Bitbucket gehosteten Runner ihn erreichen können. Verwenden Sie stattdessen einen Bitbucket selbstgehosteter Runner, sodass Ihr Pipeline-Schritt innerhalb Ihres eigenen Netzwerks läuft, genauso wie Ihr On-Prem-Server von anderen internen Tools erreicht wird.

Ergebnisse des Pipeline-Schritts

Der Connector schreibt einen Barrierefreiheitsbericht in das Zielverzeichnis (standardmäßig axe-linter-report.json), der die spezifischen gefundenen Barrierefreiheitsfehler einschließlich Dateiname und Zeilennummer enthält. Alleinige Barrierefreiheitsverletzungen ändern nicht den Exit-Code des Connectors oder lassen den Bitbucket-Schritt fehlschlagen; der Connector gibt nur einen Nicht-Nullwert zurück, bei einem Problem mit dem Scan selbst, wie z.B. einer fehlenden Option, einem unerreichbaren Server oder einem abgelehnten Schlüssel. Siehe Exit-Codes für die vollständige Liste.

note

Wenn Sie möchten, dass der Pipeline-Schritt fehlschlägt, wenn Barrierefreiheitsverletzungen gefunden werden, fügen Sie einen Skript-Schritt hinzu, der den generierten Bericht überprüft und einen Nicht-Nullwert zurückgibt, ähnlich dem im Verwendung von Axe DevTools Linter mit Jenkins gezeigten Build-Skript.

Nächste Schritte

Für Informationen zu den von Axe DevTools Linter verwendeten Regeln zur Codeprüfung siehe Barrierefreiheitsregeln. Wenn Sie den Bericht in SonarQube einspeisen möchten, siehe Verwendung von Axe DevTools Linter mit SonarQube.