Axe Watcher in Continuous-Integration-Umgebungen (CI)

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

Wie Axe Watcher CI-Pipelines erkennt und kanonische Quellen für Barrierefreiheitstest-Baselines verwendet

Not for use with personal data

Wenn Axe Watcher in einer kontinuierlichen Integration (CI) auf dem Standard-Git-Branch Ihres Repositories (z. B. main) ausgeführt wird, wird dieses Ergebnis zur kanonische Quelle (der einzige Ausgangspunkt, gegen den jeder andere Scan verglichen wird).

Was Kanonische Quelle bedeutet

  • Nur der Standard-Branch qualifiziert sich.-Pipeline-Läufe auf Feature-Branches oder Pull-Request-Branches werden aufgezeichnet, werden jedoch nicht zur kanonischen Quelle.
  • Der neueste Pipeline-Lauf gewinnt. Jeder neue CI-Lauf auf dem Standard-Branch ersetzt die vorherige Basislinie, sodass Vergleiche immer den aktuellsten CI-Status widerspiegeln.
  • Lokale Läufe vergleichen sich gegen CI. Wenn ein Entwickler Axe Watcher lokal ausführt, werden seine Ergebnisse mit der neuesten kanonischen Quelle verglichen, anstatt mit seinem eigenen letzten Scan. Dies gibt jedem Teammitglied einen gemeinsamen Referenzpunkt, anstatt individuelle, potenziell abweichende Baselines.

Erforderliche Berechtigungen

Der in Ihrer CI-Pipeline verwendete API-Schlüssel muss zu einem Projekt-Admin gehören.

important

Projektmitglieder, die keine Administratoren sind, können keine Daten über eine Pipeline senden (die Anfrage schlägt mit einem Fehler fehl).

Beim Konfigurieren Ihrer CI-Umgebung stellen Sie sicher, dass der API-Schlüssel von einem Konto mit Admin-Zugriff auf das Zielprojekt im Axe Developer Hub generiert wurde.

Pipeline-Läufe auf Nicht-Standard-Branches

Sie können Axe Watcher in CI auf jedem Branch ausführen, aber das Verhalten unterscheidet sich von Läufen auf dem Standard-Branch:

  • Ergebnisse werden „Pipeline“ zugeordnet, nicht dem einzelnen Benutzer, dessen API-Schlüssel verwendet wurde. Im Axe Developer Hub erscheinen Pipeline-Daten unter einem dedizierten „Pipeline“-Eintrag und nicht unter einem bestimmten Teammitglied.
  • Diese Läufe werden nicht zur kanonischen Quelle. Nur Pipeline-Läufe auf dem Standard-Branch setzen die Ausgangsbasis für Vergleiche.
  • Feature-Branch-Ergebnisse werden dennoch aufgezeichnet. Sie sind im Axe Developer Hub sichtbar, wenn die „Pipeline“-Ansicht ausgewählt ist, was nützlich ist, um Barrierefreiheit bei Pull-Requests vor dem Zusammenführen zu überprüfen.

CI-Erkennung

Axe Watcher bestimmt, ob es in CI läuft, über Umgebungsvariablen:

  1. Standard-CI-Variable: Wenn CI auf true gesetzt ist, behandelt Watcher den Lauf als Pipeline-Ausführung und setzt die kanonische Quelle entsprechend. Die meisten CI-Plattformen setzen dies automatisch (siehe Plattformunterstützung).

  2. Explizites Überschreiben: AXE_IS_CI hat Vorrang vor CI, wenn beide vorhanden sind.

    Verwenden Sie AXE_IS_CI, wenn die standardmäßige CI-Variable nicht Ihren Anforderungen entspricht:

    • CI-Modus in einer nicht standardmäßigen Umgebung aktivieren, zum Beispiel ein selbst gehosteter Runner oder ein geplanter Task, der CI nicht auf true setzt, indem AXE_IS_CI auf true gesetzt wird.

    • CI-Modus in einer Pipeline deaktivieren, um beispielsweise einen erkundenden Scan in CI auszuführen, ohne die kanonische Quelle zu überschreiben, indem Sie AXE_IS_CI auf false setzen.

Wenn AXE_IS_CI gesetzt ist, wird der Wert von CI vollständig ignoriert.

Plattformunterstützung

Plattform CI setzt true standardmäßig Dokumentation
GitHub Actions ja GitHub-Dokumentationen - Variablenreferenz
GitLab CI ja GitLab-Dokumentationen - Vordefinierte Variablen
CircleCI ja CircleCI-Dokumentation – Projektwerte und Variablen
Bitbucket Pipelines ja Atlassian Support – Variablen und Geheimnisse
Jenkins nein (CI=true oder AXE_IS_CI=true in Ihrem environment-Block setzen) Verwendung von Umgebungsvariablen

API-Schlüsselentzug

Wenn der in Ihrer CI-Pipeline verwendete API-Schlüssel gelöscht oder das zugehörige Benutzerkonto deaktiviert wird, wird die Authentifizierung von Pipeline-Ausführungen nicht mehr erfolgreich sein. Zuvor aufgezeichnete Ergebnisse bleiben im Axe Developer Hub sichtbar, aber keine neuen Daten können gesendet werden, bis die Pipeline mit einem gültigen Admin-API-Schlüssel neu konfiguriert wird.

Um CI-Fehler zu vermeiden, wenn Teammitglieder das Unternehmen verlassen oder Schlüssel wechseln, sollten Sie die Verwendung eines dedizierten Dienstkontos für Pipeline-API-Schlüssel in Betracht ziehen.