Integrationen

Die GitHub-Prüfung für Pull Requests

Aktualisiert: 25. Oktober 2026 Für: Entwickler Tarif: Professional und höher

Eine Änderung am Warenkorb-Template besteht das Code-Review, die Tests sind grün, und eine Woche später fehlt purchase im Report. Die Prüfung in Pull Requests verlegt diesen Moment vor den Merge: Wir spielen jeden Pull Request auf seiner Preview-Umgebung mit denselben Journeys ab, die Sie in der Produktion überwachen, und schreiben das Ergebnis als Check mit dem Namen AnalyticsProof auf GitHub.

Pull Request → Preview-URL (aus GitHub Deployments oder aus einer Vorlage) → Wiedergabe aller aktiven Journeys als Dry-Run → Check. Der gespeicherte erwartete Zustand wird nur gelesen, nie geschrieben. Rot sind nur die Ausgänge, die blockieren: eine kritische dataLayer-Änderung oder eine Preview, die nicht gemessen werden konnte.

Was Sie brauchen

Ein Projekt im Professional-Plan oder höher und einen Website- oder HbbTV-Test mit mindestens einer aufgezeichneten Journey. Die Schaltfläche „GitHub verbinden“ finden Sie auf der Seite des Tests. Die GitHub-Verbindung können Bearbeiter und höher ändern; alle anderen sehen die Schaltfläche ausgegraut.
Eine Preview-Umgebung, die für jeden Pull Request unter einer eigenen https-Adresse bereitsteht. Sie darf hinter einem Passwort oder einer IP-Allowlist liegen; beides stellen Sie im dritten Schritt ein.
Journeys, die in der Zeitzone des Scan-Landes aufgezeichnet wurden. Passt eine nicht, nennt der Dialog sie und empfiehlt, sie vor dem Aktivieren neu aufzuzeichnen.

Die Einrichtung hat drei Schritte: Repository, Preview-URL und Zugang.

Schritt 1: Repository

Klicken Sie auf „GitHub autorisieren“. In einem neuen Tab erlauben Sie den Zugriff auf GitHub; danach sehen wir die Repositories, die Sie ändern dürfen. Ist die AnalyticsProof App in Ihrer Organisation noch nicht installiert, erscheint der Link „AnalyticsProof App auf GitHub verbinden“. Wählen Sie bei der Installation „Only select repositories“ und haken Sie nur das Repository der Website an. Zurück im Dialog nutzen Sie „Repositories aktualisieren“ und wählen es unter „Website-Repository“ aus.

Der Dialog Prüfung in Pull Requests, Schritt Repository mit ausgewähltem Repository — Schritt 1: das Repository der Website. Ein Repository kann nur mit einem Test verbunden sein.

Schritt 2: Preview-URL

Unter „Woher die Preview-URL kommt“ gibt es zwei Möglichkeiten.

Aus GitHub Deployments. Passt, wenn Ihr Hosting oder Ihre Pipeline die Deployments von Pull Requests an GitHub meldet. Wir warten auf ein Deployment des Commits aus dem Pull Request mit dem Status success und einer Umgebungs-URL (environment_url). Bis es da ist, zeigt der Check, dass er auf die Adresse wartet. Kommt innerhalb von 10 Minuten nach dem Start des Checks nichts, endet der Check neutral.

Aus einer URL-Vorlage. Passt, wenn die Preview-Adresse vorhersehbar ist. Die Vorlage kennt diese Platzhalter:

Platzhalter	Wird ersetzt durch
`{branch}`	Der Branch-Name in Kleinbuchstaben, jede Folge anderer Zeichen durch einen Bindestrich ersetzt
`{pr}`	Die Nummer des Pull Requests
`{sha}`	Der vollständige Commit-Hash
`{sha7}`	Die ersten sieben Zeichen des Commit-Hashes

Unter dem Feld sehen Sie sofort, wie die Adresse für den Branch feature/checkout aussähe. Die Vorlage muss per https:// auf eine öffentliche Domain führen, ohne Portnummer, ohne Benutzername und Passwort in der Adresse und ohne IP-Adresse. Lokale Namen (.local, .internal, .test, .example und ähnliche) lehnt der Dialog ab. Eine Vorlage ganz ohne Platzhalter wird angenommen, aber der Dialog weist darauf hin, dass dann jeder Pull Request gegen dieselbe Adresse getestet wird.

Der Schritt Preview-URL mit einer URL-Vorlage und der daraus entstehenden Beispieladresse — Schritt 2: die URL-Vorlage. Die Zeile unter dem Feld zeigt die Adresse für einen Beispiel-Branch.

Schritt 3: Zugang

Passwort der Preview. Liegt die Preview hinter Basic Auth, haken Sie „Die Preview verlangt Benutzername und Passwort (Basic Auth)“ an und füllen beides aus. Der Browser schickt die Daten nur an den Origin der Preview, nie an andere Dienste auf der Seite. Das Passwort wird als Klartext gespeichert, und Bearbeiter können es im Dialog lesen. Nehmen Sie deshalb einen eigenen Zugang nur für die Preview, kein persönliches Konto.

IP-Allowlist. Im Feld „Erlauben Sie unsere IP“ steht die Adresse, von der wir scannen. Sie richtet sich nach dem Land, das beim Anlegen des Tests gewählt wurde, und auch die Scans der Pull Requests kommen von dort. Tragen Sie sie in die Allowlist der Preview-Umgebung ein.

„Prüfen und speichern“ versucht zuerst, die Preview zu öffnen: DNS, TLS-Handshake, HTTP-Antwort, Seiten-Rendering und DataLayer. Gespeichert wird nur, wenn diese Prüfung besteht (die Ausnahme für {pr} im Hostnamen beschreibt der nächste Absatz). Schlägt sie fehl, sehen Sie, an welchem Schritt und was zu tun ist.

In diesem Moment gibt es noch keinen Pull Request, deshalb nimmt die Prüfung den Standard-Branch des Repositorys und dessen letzten Commit. In die Vorlage kommt der Name des Standard-Branches, und {pr} wird zu null. Steht {pr} im Hostnamen (zum Beispiel https://pr-{pr}.preview.example.com), gibt es die Adresse mit null meist nicht, weil die Preview erst mit einem Pull Request entsteht. Antwortet sie nicht, bietet der Dialog „Trotzdem speichern“ an, und die echte Adresse verwendet erst die Prüfung des ersten Pull Requests. Eine Vorlage ohne {pr} im Hostnamen muss die Prüfung bestehen, auch wenn {pr} im Pfad oder in den Parametern steht. Bei GitHub Deployments braucht der letzte Commit des Standard-Branches ein erfolgreiches Deployment. Fehlt es, bietet der Dialog „Trotzdem speichern“ an.

Nach dem Speichern bietet der Dialog „Prüfung ausführen“ an. Sie spielt die Journeys gegen dieselbe Adresse ab wie die Prüfung, und „Ergebnisse öffnen“ führt zum Ergebnis im Dashboard. So testen Sie die ganze Einrichtung am schnellsten, bevor ein Kollege ihr in seinem Pull Request begegnet. Steht {pr} im Hostnamen, bietet der Dialog keine Probeprüfung an, weil die Adresse mit null nicht existiert. Dort ist der erste Pull Request der eigentliche Test.

Der Schritt Zugang mit ausgefülltem Basic Auth, der IP-Adresse und bestandener Prüfung — Schritt 3: Zugang zur Preview. Nach dem Speichern zeigt der Dialog das Prüfergebnis und bietet einen Probelauf an.

Was der Check meldet

Der Check läuft, wenn ein Pull Request geöffnet, mit einem neuen Push aktualisiert, wieder geöffnet oder als bereit für das Review markiert wird. Ein Entwurf (Draft) bekommt einen neutralen Check und wird abgespielt, sobald er bereit für das Review ist. Ein Commit, der schon ein bestandenes oder fehlgeschlagenes Ergebnis hat, behält es, solange der Pull Request ein Entwurf ist. „Re-run“ im Check funktioniert höchstens dreimal pro Commit und Stunde. Über diesem Limit lautet der Check AnalyticsProof — re-run limit reached, es sei denn, der Commit hat schon ein bestandenes oder fehlgeschlagenes Ergebnis oder wird gerade gemessen: Dann ändert der Klick nichts, und dieses Ergebnis gilt. Kommt inzwischen ein neuerer Push, endet der Check des älteren Commits neutral, und das Ergebnis wird nur zum neuesten Commit geschrieben.

Alle aktiven Journeys des Tests werden abgespielt, jede ab der Preview-URL. Sie laufen als Dry-Run: Es entstehen Abweichungen und ein Ergebnis für den Check, aber in die Journey und ihren erwarteten Zustand wird nichts geschrieben. Mehr zum Dry-Run steht in der Anleitung CI/CD mit der API.
Es zählt nur, was die Website direkt in ihren Data Layer schreibt: in window.dataLayer und auf Websites mit dem Adobe Client Data Layer auch in window.adobeDataLayer. Anfragen, die Tools wie GA4 oder Adobe Analytics daraus weiterschicken, bleiben im Dashboard; für sie ist ein Entwickler, der die Website ändert, nicht direkt verantwortlich.
Bewertet wird nur, was der Pull Request mitbringt. Die Abweichungen werden mit dem letzten Produktionsscan der Journey verglichen, und der Kommentar im Pull Request trennt sie in „New in this PR“ und „Already on production“. Wurde die Produktion noch nie gescannt, gilt alles als neu.
Nur kritische Änderungen blockieren. Typisch ist ein Event, das der erwartete Zustand verlangt und das im Schritt fehlt (sofern Sie es nicht als optional markiert haben). Ein neues Event, ein fehlender Parameter oder ein anderer Parametertyp sind Warnungen: Der Kommentar führt sie auf, der Check bleibt aber grün. Werte von Parametern vergleichen wir nicht, nur ihr Vorhandensein und ihren JavaScript-Typ. Im Dashboard tragen kritische Änderungen eine rote, Warnungen eine orange Markierung.
Eine Journey, die nicht gemessen werden konnte, ist nicht grün. Schlägt der Scan einer Journey fehl, misst er nichts oder bleibt die Journey schon beim ersten Schritt stehen, wird der Check rot, auch ohne eine einzige Änderung. Eine Journey, die erst bei einem späteren Schritt stehen bleibt, ist nur eine Warnung: Wahrscheinlich hat sie eine größere Änderung der Website unterbrochen, nicht dieser Pull Request.

Check und Kommentar sind auf Englisch, egal in welcher Sprache Ihr Dashboard läuft. Sie werden von den Reviewern des Repositorys gelesen, und der Name des Checks muss für den Branch-Schutz stabil bleiben.

Den Check verpflichtend machen

Sobald der Check einmal bestanden hat, können Sie ihn auf GitHub als erforderlich festlegen. Aktivieren Sie in den Branch-Protection-Regeln oder in einem Ruleset des Repositorys erforderliche Status-Checks und wählen Sie AnalyticsProof. GitHub bietet nur Checks an, die im Repository kürzlich gelaufen sind, deshalb geht das erst nach dem ersten Lauf.

Beachten Sie, dass GitHub ein neutrales Ergebnis als erfüllt wertet. Ein Pull Request, für den keine Preview gefunden wurde, ein Entwurf oder ein Pull Request, bei dem sich keine Journey vergleichen ließ, blockiert den Merge also nicht.

Wenn der Check nicht tut, was Sie erwarten

Titel des Checks	Was er bedeutet	Was zu tun ist
`AnalyticsProof — critical dataLayer change`	Eine Journey hat eine kritische Änderung gefunden.	Die Tabelle im Check zeigt Status und Befunde jeder Journey; die Details liegen hinter dem Ergebnis-Link.
`AnalyticsProof — preview could not be measured`	Keine Journey hat eine kritische Änderung gefunden, aber mindestens eine konnte nicht gemessen werden: Die Preview ließ sich nicht öffnen, der Scan hat nichts gemessen, die Journey blieb beim ersten Schritt stehen oder konnte nicht gestartet werden, oder das Ergebnis war unvollständig.	Prüfen Sie, dass die Preview-Adresse funktioniert und unseren Browser hereinlässt (Passwort, IP-Allowlist). Der Kommentar nennt jede betroffene Journey.
`AnalyticsProof — superseded by a newer commit`	In den Pull Request kam ein neuerer Commit, bevor dieser fertig war.	Nichts. Das Ergebnis steht im Check des neuesten Commits.
`AnalyticsProof — waiting for a preview URL`	Es kam noch kein Deployment mit Adresse, oder die Adresse aus der Vorlage war nicht verwendbar.	Prüfen Sie, dass das Hosting ein Deployment zum Commit des Pull Requests meldet, oder korrigieren Sie die Vorlage.
`AnalyticsProof — nothing measurable`	Keine Journey ließ sich vergleichen, meist weil noch keine einen erwarteten Zustand hat. Sobald sich mindestens eine Journey vergleichen lässt, ist der Check nach ihr grün oder rot, und die Tabelle führt die übrigen mit dem Grund auf.	Warten Sie, bis die Journeys ihren erwarteten Zustand aufgebaut haben; der Stand ist an der Journey im Dashboard zu sehen.
`AnalyticsProof — nothing to run`	Der Test hat keine aktive Journey.	Zeichnen Sie eine Journey auf oder setzen Sie eine pausierte fort.
`AnalyticsProof — interrupted, not judged`	AnalyticsProof wurde durch unsere eigene Wartung oder einen Neustart unterbrochen (auch durch ein Herunterfahren oder einen Ausfall unserer Datenbank), bevor jede Journey gemessen war, oder ein Scan wartete beim Ablauf der 15-Minuten-Frist noch in unserer Warteschlange. Ein Scan, den unser Scanner abgelehnt hat oder bei dem er fehlgeschlagen ist (etwa ein ausgelasteter oder rate-limitierter Scanner), erscheint weiterhin als `AnalyticsProof — preview could not be measured`. Nichts im Pull Request wurde als Fehler bewertet, der neutrale Check blockiert den Merge also nicht. Solange der Check es selbst erneut versucht, lautet sein Titel `AnalyticsProof — interrupted, retrying…`.	Klicken Sie im Check auf „Re-run“, um erneut zu messen.
`AnalyticsProof — re-run interrupted, previous failure stands`	Ein Re-run eines Commits, der bereits fehlgeschlagen war, wurde auf unserer Seite unterbrochen, bevor jede Journey gemessen war. Das bisherige Fehlschlagen gilt weiter, der Check bleibt also rot.	Klicken Sie im Check auf „Re-run“, um erneut zu messen.
`AnalyticsProof — re-run not judged, previous failure stands`	Ein Re-run eines Commits, der bereits fehlgeschlagen war, endete, ohne etwas zu bewerten (etwa ohne Vorschau-URL, ohne ausführbare Journey oder ohne Messbares). Das bisherige Fehlschlagen gilt weiter, der Check bleibt also rot; der Grund steht in der Zusammenfassung.	Beheben Sie den Grund aus der Zusammenfassung und klicken Sie dann auf „Re-run“.
`AnalyticsProof — Professional plan required`	Das Projekt ist nicht im Professional-Plan oder höher.	Die Prüfung in Pull Requests gehört zum Professional-Plan und höher.
`AnalyticsProof — not configured`	Die App ist im Repository installiert, aber das Repository ist mit keinem Test verbunden.	Verbinden Sie es im GitHub-Dialog des Tests, oder entfernen Sie das Repository aus der Installation der App.
`AnalyticsProof — will run once the PR is ready for review`	Der Pull Request ist ein Entwurf.	Markieren Sie ihn als bereit für das Review; der Check läuft dann von selbst.
`AnalyticsProof — re-run limit reached`	„Re-run“ wurde für diesen Commit in der letzten Stunde dreimal genutzt. Ein bestandenes oder fehlgeschlagenes Ergebnis, das der Commit schon hat oder das gerade gemessen wird, ersetzt dieser Check nicht.	Versuchen Sie es später erneut, oder pushen Sie einen neuen Commit.

Eine häufige Ursache für einen roten Check liegt aber gar nicht im dataLayer. Die Preview weist unseren Browser ab, weil die IP auf der Allowlist fehlt oder das Passwort nicht stimmt. Führen Sie „Prüfen und speichern“ erneut aus; es zeigt genau, an welchem Schritt der Zugang scheitert.

Kein GitHub, oder wollen Sie Ihr eigenes Gate bauen? Dasselbe leistet die API: Die Anleitung CI/CD mit der API beschreibt den Ablauf, die CI-Rezepte sind fertig zum Übernehmen.

Haben Sie in dieser Anleitung einen Fehler gefunden, oder fehlt etwas? Schreiben Sie uns

Alle Anleitungen