Integrace

Kontrola pull requestů na GitHubu

Aktualizováno: 25. října 2026 Pro koho: vývojář Tarif: Professional a vyšší

Změna v šabloně košíku projde code review, testy jsou zelené a o týden později chybí v reportu purchase. Kontrola pull requestů tohle přesouvá před merge: každý pull request přehrajeme na jeho preview prostředí stejnými cestami, jaké hlídáte na produkci, a výsledek zapíšeme do GitHubu jako check s názvem AnalyticsProof.

Pull request → adresa preview (z GitHub Deployments, nebo ze šablony) → přehrání všech aktivních cest v režimu dry-run → check. Uložený očekávaný stav se jen čte, nic se do něj nezapisuje. Červeně jen závěry, které blokují: kritická změna v dataLayeru, nebo preview, které se nedalo změřit.

Co potřebujete

Projekt na tarifu Professional nebo vyšším a test webu nebo HbbTV aplikace s aspoň jednou nahranou cestou. Tlačítko „Připojit GitHub“ je na stránce testu. Propojení s GitHubem může měnit editor nebo vyšší role, ostatní tlačítko vidí zašedlé.
Preview prostředí, které se pro pull request nasadí na vlastní adresu přes https. Může být za heslem nebo za IP allowlistem, obojí se nastaví ve třetím kroku.
Cesty nahrané v časovém pásmu země skenu. Když se pásmo neshoduje, dialog cestu vyjmenuje a doporučí ji nahrát znovu, než kontrolu zapnete.

Nastavení má tři kroky: Repozitář, Preview URL a Přístup.

Krok 1: Repozitář

Klikněte na „Autorizovat GitHub“. V novém panelu povolíte na GitHubu přístup a my pak uvidíme repozitáře, které smíte měnit. Pokud aplikace AnalyticsProof ve vaší organizaci ještě není nainstalovaná, objeví se odkaz „Připojit AnalyticsProof App na GitHubu“. Při instalaci stačí zvolit „Only select repositories“ a zaškrtnout jen repozitář webu. Po návratu použijte „Obnovit repozitáře“ a vyberte repozitář v poli „Repozitář webu“.

Dialog Kontrola v pull requestech, krok Repozitář s vybraným repozitářem — Krok 1: repozitář webu. Jeden repozitář může být propojený jen s jedním testem.

Krok 2: Preview URL

V poli „Odkud vezmeme adresu preview“ jsou dvě možnosti.

Z GitHub Deployments. Hodí se, když váš hosting nebo pipeline zapisuje nasazení pull requestu do GitHubu. Čekáme na deployment commitu z pull requestu se stavem success a vyplněnou adresou prostředí (environment_url). Dokud se neobjeví, check ukazuje, že na adresu čeká. Když nepřijde do 10 min od spuštění checku, check skončí jako neutrální.

Ze šablony adresy. Hodí se, když má preview předvídatelnou adresu. Do šablony dáte zástupné symboly:

Zástupný symbol	Dosadí se
`{branch}`	Název větve malými písmeny, každý úsek jiných znaků nahradí pomlčka
`{pr}`	Číslo pull requestu
`{sha}`	Celý hash commitu
`{sha7}`	Prvních sedm znaků hashe commitu

Pod polem hned vidíte ukázku, jak by adresa vypadala pro větev feature/checkout. Šablona musí vést na veřejnou doménu přes https://, bez čísla portu, bez jména a hesla v adrese a bez IP adresy. Lokální názvy (.local, .internal, .test, .example a podobné) dialog odmítne. Šablona bez zástupného symbolu projde, ale dialog upozorní, že by se každý pull request testoval na stejné adrese.

Krok Preview URL se šablonou adresy a ukázkou výsledné adresy — Krok 2: šablona adresy. Ukázka pod polem ukazuje adresu pro vzorovou větev.

Krok 3: Přístup

Heslo k preview. Pokud je preview za Basic auth, zaškrtněte „Preview vyžaduje jméno a heslo (Basic auth)“ a vyplňte údaje. Prohlížeč je pošle jen adrese preview, ne dalším službám na stránce. Heslo je uložené jako běžný text a editoři ho v dialogu vidí. Použijte proto samostatné přihlášení jen pro preview, ne osobní účet.

IP allowlist. V poli „Povolte naši IP“ je adresa, ze které skenujeme. Určuje ji země, kterou jste zvolili při vytvoření testu, a pod stejnou adresou běží i skeny pull requestů. Přidejte ji na allowlist preview prostředí.

„Ověřit a uložit“ nejdřív zkusí preview otevřít: DNS, TLS handshake, HTTP odpověď, vykreslení stránky a DataLayer. Uloží se, jen když ověření projde (výjimku pro {pr} v adrese serveru popisuje další odstavec). Když selže, uvidíte, na kterém kroku a co s tím.

Žádný pull request v tu chvíli není, proto ověření použije výchozí větev repozitáře a její poslední commit. Do šablony dosadí název výchozí větve a {pr} vyplní nulou. Když je {pr} v adrese serveru (například https://pr-{pr}.preview.example.com), adresa s nulou obvykle neexistuje, protože náhled vzniká až s pull requestem. Když neodpovídá, dialog nabídne „Uložit i tak“ a skutečnou adresu použije až kontrola prvního pull requestu. Šablona bez {pr} v adrese serveru musí ověřením projít, i když má {pr} v cestě nebo parametrech. U GitHub Deployments musí mít úspěšný deployment poslední commit výchozí větve. Když ho nemá, dialog nabídne „Uložit i tak“.

Po uložení je v dialogu „Spustit kontrolu“. Přehraje cesty na stejné adrese jako ověření a odkaz „Otevřít výsledky“ vede na výsledek v dashboardu. Je to nejrychlejší způsob, jak ověřit celé nastavení dřív, než ho uvidí kolegové na svém pull requestu. U šablony s {pr} v adrese serveru dialog zkušební kontrolu nenabízí, protože adresa s nulou neexistuje. Skutečným testem je tam první pull request.

Krok Přístup s vyplněným Basic auth, IP adresou a úspěšným ověřením — Krok 3: přístup k preview. Po uložení dialog ukáže výsledek ověření a nabídne zkušební kontrolu.

Co check hlásí

Kontrola běží, když pull request otevřete, pushnete do něj, znovu ho otevřete nebo ho označíte jako připravený k review. Rozpracovaný pull request (draft) dostane neutrální check a přehraje se, až bude připravený k review. Commit, který už má výsledek „prošlo“ nebo „neprošlo“, si ho po dobu draftu ponechá. „Re-run“ u checku funguje nejvýš třikrát za hodinu pro jeden commit. Nad tento limit má check titulek AnalyticsProof — re-run limit reached, ledaže commit už má výsledek „prošlo“ nebo „neprošlo“, nebo se právě měří: pak kliknutí nic nezmění a platí tento výsledek. Pokud mezitím přišel novější push, check staršího commitu skončí jako neutrální a výsledek se zapíše jen k nejnovějšímu commitu.

Přehrají se všechny aktivní cesty testu, každá od adresy preview. Běží v režimu dry-run: vzniknou rozdíly a výsledek pro check, ale do cesty ani do jejího očekávaného stavu se nic nezapíše. Víc o dry-runu je v návodu CI/CD přes API.
Počítá se jen to, co web posílá přímo do své datové vrstvy: do window.dataLayer a na webech s Adobe Client Data Layer také do window.adobeDataLayer. Požadavky, které z toho dál posílají nástroje jako GA4 nebo Adobe Analytics, zůstávají v dashboardu. Za ty vývojář změnou webu přímo neodpovídá.
Posuzuje se jen to, co přinesl pull request. Rozdíly porovnáme s posledním produkčním skenem cesty. Komentář v pull requestu je rozdělí na „New in this PR“ a „Already on production“. Pokud produkce ještě skenovaná nebyla, bere se všechno jako nové.
Blokují jen kritické změny. Typicky je to událost, která v očekávaném stavu je, ale v kroku chybí (pokud ji nemáte jako volitelnou). Nová událost, chybějící parametr nebo jiný typ parametru jsou varování: v komentáři je uvidíte, ale check kvůli nim nezčervená. Hodnoty parametrů neporovnáváme, jen jejich přítomnost a typ v JavaScriptu. V dashboardu mají kritické změny červenou a varování oranžovou značku.
Neměřitelná cesta není zelená. Když se sken cesty nepovede, nic nezměří nebo se cesta zastaví hned na prvním kroku, check zčervená, i když žádnou změnu nenašel. Cesta, která se zastaví až na některém z dalších kroků, je jen varování: nejspíš ji rozbila větší změna webu, ne tenhle pull request.

Text checku i komentáře je anglicky, i když máte dashboard česky. Čtou ho reviewři repozitáře a název checku musí zůstat stejný kvůli ochraně větve.

Povinný check

Až check poprvé projde, můžete ho v GitHubu nastavit jako povinný. V ochraně větve nebo v pravidlech repozitáře zapněte požadované status checky a vyberte AnalyticsProof. GitHub nabízí jen checky, které v repozitáři nedávno proběhly, proto to jde až po prvním běhu.

Počítejte s tím, že GitHub bere neutrální výsledek jako splněný. Pull request, pro který se preview nenašlo, draft nebo pull request, u kterého se nedala porovnat žádná cesta, tedy merge nezablokuje.

Když check nedělá, co čekáte

Titulek checku	Co znamená	Co s tím
`AnalyticsProof — critical dataLayer change`	Některá cesta našla kritickou změnu.	V tabulce checku je u každé cesty stav a nálezy. Detail je pod odkazem na výsledek.
`AnalyticsProof — preview could not be measured`	Žádná cesta nenašla kritickou změnu, ale aspoň jedna se nedala změřit: preview se neotevřelo, sken nic nezměřil, cesta se zastavila na prvním kroku nebo se ji nepodařilo spustit, nebo výsledek nebyl úplný.	Ověřte, že adresa preview funguje a pustí náš prohlížeč dovnitř (heslo, povolené IP). Komentář vypíše každou dotčenou cestu.
`AnalyticsProof — superseded by a newer commit`	Do pull requestu přišel novější commit dřív, než tenhle doběhl.	Nic. Výsledek je u checku nejnovějšího commitu.
`AnalyticsProof — waiting for a preview URL`	Deployment s adresou zatím nepřišel, nebo adresu ze šablony nebylo možné použít.	Zkontrolujte, že hosting zapisuje deployment ke commitu z pull requestu, nebo opravte šablonu.
`AnalyticsProof — nothing measurable`	Nedala se porovnat ani jedna cesta, typicky proto, že žádná ještě nemá očekávaný stav. Jakmile jde porovnat aspoň jedna cesta, check je podle ní zelený nebo červený a ostatní cesty tabulka vypíše i s důvodem.	Počkejte, až se cestám založí očekávaný stav. Stav uvidíte u cesty v dashboardu.
`AnalyticsProof — nothing to run`	Test nemá žádnou aktivní cestu.	Nahrajte cestu nebo obnovte pozastavenou.
`AnalyticsProof — interrupted, not judged`	Měření přerušila naše údržba nebo restart (včetně vypnutí nebo selhání naší databáze) dřív, než proběhlo u všech cest, nebo sken po uplynutí 15minutového limitu pořád čekal v naší frontě. Sken, který náš skener odmítl nebo při kterém selhal (třeba přetížený skener nebo skener nad limitem požadavků), se dál ukazuje jako `AnalyticsProof — preview could not be measured`. Nic v pull requestu nebylo posouzené jako chyba, takže neutrální check merge neblokuje. Dokud se check zkouší znovu sám, má titulek `AnalyticsProof — interrupted, retrying…`.	Klikněte u checku na „Re-run“ a měření proběhne znovu.
`AnalyticsProof — re-run interrupted, previous failure stands`	Opakované měření commitu, který předtím neprošel, se na naší straně přerušilo dřív, než proběhlo u všech cest. Původní neúspěch platí dál, takže check zůstává červený.	Klikněte u checku na „Re-run“ a měření proběhne znovu.
`AnalyticsProof — re-run not judged, previous failure stands`	Opakované měření commitu, který předtím neprošel, skončilo, aniž by cokoli posoudilo (třeba bez adresy náhledu, bez cest ke spuštění nebo bez čeho měřit). Původní neúspěch platí dál, takže check zůstává červený; důvod je ve shrnutí.	Opravte důvod ze shrnutí a klikněte na „Re-run“.
`AnalyticsProof — Professional plan required`	Projekt není na tarifu Professional ani vyšším.	Kontrola pull requestů je součástí plánu Professional a vyšších.
`AnalyticsProof — not configured`	Aplikace je na repozitáři nainstalovaná, ale repozitář není propojený s žádným testem.	Propojte ho v dialogu GitHubu na stránce testu, nebo repozitář z instalace aplikace odeberte.
`AnalyticsProof — will run once the PR is ready for review`	Pull request je draft.	Označte ho jako připravený k review, check se pak spustí sám.
`AnalyticsProof — re-run limit reached`	„Re-run“ u tohoto commitu proběhl během poslední hodiny třikrát. Výsledek „prošlo“ nebo „neprošlo“, který commit už má nebo který se právě měří, tento check nenahradí.	Zkuste to později, nebo pushněte nový commit.

Častý důvod červeného checku ale není v dataLayeru. Preview odmítne náš prohlížeč, protože chybí IP na allowlistu nebo nesedí heslo. Pusťte „Ověřit a uložit“ znovu, ukáže přesně, na kterém kroku přístup selhal.

Nepoužíváte GitHub, nebo chcete bránu poskládat po svém? Totéž umí API: postup popisuje návod CI/CD přes API, hotové recepty jsou v referenci pro CI.

Našli jste v návodu chybu, nebo vám v něm něco chybí? Napište nám

Všechny návody