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 Quellebedeutet

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:

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

Stellen Sie sicher, dass CI Git-Informationen bereitstellt

Ein Git-Projekt wird bei seiner ersten erfolgreichen Sitzung an ein einzelnes Repository gebunden, und jeder spätere Lauf, der ohne vollständige Git-Informationen ankommt, wird abgelehnt, anstatt als Gitless akzeptiert zu werden. CI-Umgebungen sind die häufigste Quelle für unvollständige Git-Informationen:

Flache Klone (git clone --depth 1, oder das Standard-Checkout-Verhalten einer CI-Plattform) kann die Daten weglassen, die Watcher benötigt, um den Branch oder Commit zuverlässig zu erkennen. Erhöhen Sie die Abruftiefe oder liefern Sie die fehlenden Felder explizit mit AxeWatcherGitInfo (Java) oder den expliziten Feldern der git-Konfiguration (JavaScript/TypeScript).
Detacher HEAD-Zustand, häufig, wenn CI einen bestimmten Commit anstelle eines Branches auscheckt, kann den Branch-Namen unauffindbar machen. Geben Sie den Branch explizit an, wenn Ihre Plattform ihn nicht anderweitig bereitstellt.
Ein fehlendes origin-Remote entfernt die Repository-URL, die identifiziert, zu welchem Repository der Lauf gehört.

Siehe Bereitstellung von Git-Metadaten, um zu erfahren, wie Sie diese Felder explizit bereitstellen können, und Lauf abgelehnt: Datenstruktur oder Repository stimmt nicht mit dem Projekt überein, wenn ein Lauf bereits abgelehnt wurde.

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.