Din pull request ser bra ut. Testerna godkänns. Sedan trycker någon på en djup länk i staging och ingenting händer. Nu letar du igenom manifests, routes och skärmdumpar med ”det funkar på min telefon” i stället för att slå ihop PR:en.
Den här automatiseringen för GitHub PR comments slår ärligt talat hårdast mot mobilteam. Men CI-ingenjörer och maintainers som granskar många PR:er känner också av det. Resultatet är enkelt: varje push till en PR får en tydlig tabell med godkänd/underkänd postad direkt i konversationen, så trasiga routes fixas innan de går ut.
Nedan ser du hur workflowet körs, vad du behöver och hur mycket tid (och fram-och-tillbaka) du kan sluta slösa när djup länk-kontroller blir automatiska.
Så fungerar den här automatiseringen
Hela n8n-workflowet, från trigger till slutresultat:
n8n Workflow Template: GitHub PR-kommentarer som fångar korrupta djuplänkar
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>GitHub PR Webhook"]
n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "CONFIG - Variables", pos: "b", h: 48 }
n2@{ icon: "mdi:cog", form: "rounded", label: "Run Validation Script", pos: "b", h: 48 }
n3@{ icon: "mdi:code-braces", form: "rounded", label: "Format Markdown", pos: "b", h: 48 }
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>GitHub"]
n3 --> n4
n0 --> n1
n1 --> n2
n2 --> n3
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 api
class n3 code
classDef customIcon fill:none,stroke:none
class n0,n4 customIcon
Problemet: djupa länkar går sönder tyst (tills de inte gör det)
Djupa länkar är lömska eftersom de kan fallera på sätt som vanliga tester inte fångar. Ett stavfel i en host, en skärm som bytt namn, en manifest-ändring som inte speglades till iOS, eller en ny routingregel som bara slår sönder vissa paths. Granskare klickar sällan igenom varje URI i en PR, och QA ska inte lägga sin dag på att kopiera länkar till Anteckningar och testa dem en och en. Värst är tajmingen: du upptäcker ofta felet efter merge, när det är svårare att spåra vad som ändrades och folk börjar peka finger.
Friktionen byggs på. Några ”små” missar blir snabbt en diskussion om release-risk.
- Manuell testning av djupa länkar under granskning lägger ofta till 30–60 minuter per PR när du har mer än en handfull routes.
- Trasiga routes skapar stökiga kommentarer som ”kan du testa detta på Android också?”, vilket drar ut granskningar över flera dagar.
- Folk utgår från att länkarna är okej eftersom enhetstesterna är gröna, så fel smiter in i staging och ibland produktion.
- När länkar går sönder efter merge blir fixen ofta en brådskande uppföljnings-PR med mindre noggrann granskning.
Lösningen: validera varje djup länk vid varje PR-push
Det här n8n-workflowet gör validering av djupa länkar till något granskare kan lita på utan extra arbete. Varje gång en PR-branch får en ny push hämtar n8n PR-kontexten, klonar branchen och kör ett litet valideringsskript mot din deep-link-manifest (AndroidManifest.xml, Info.plist eller vilken fil du än pekar ut). Skriptet startar en emulator/simulator, testar varje deklarerad URI och skriver ut ett enkelt OK/FAIL-resultat. n8n omvandlar sedan utdata till en Markdown-tabell och postar den direkt som en PR-kommentar, så resultatet syns där teamet redan jobbar.
Workflowet startar på en PR-händelse av typen ”synchronize” (en push till PR-branchen). Därifrån skickar det ditt repo-URL och sökvägar in i ett Execute Command-steg, bygger matrisen för godkänd/underkänd och avslutar genom att publicera tabellen tillbaka till GitHub som en kommentar.
Det du får: automatisering vs. resultat
| Vad det här workflowet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att din app har runt 25 djupa länkar i manifestet. Manuellt kanske en granskare testar 10 av dem (för att ingen har tid) på kanske 2 minuter styck när du räknar in att starta appen och navigera tillbaka, så det blir ungefär 20 minuter per PR och ändå ofullständigt. Med det här workflowet pushar du din commit, n8n kör skriptet i bakgrunden och en tabell med godkänd/underkänd landar i PR-kommentarsflödet när emulator-körningen är klar (ofta runt 10–15 minuter beroende på din runner). Nettoeffekt: du slutar lägga mänsklig granskningstid på något en bot kan göra konsekvent.
Det här behöver du
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- GitHub för att läsa PR-händelser och posta kommentarer.
- Execute Command (runner) för att klona repot och köra valideringen.
- GitHub Personal Access Token (skapa den i GitHub Developer settings med repo-scope)
Kunskapsnivå: Medel. Du klistrar in ett workflow i n8n, lägger till credentials och pekar ut en skriptsökväg och manifestsökväg i ditt repo.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
En PR-uppdatering drar igång det. När någon pushar commits till en pull request-branch triggar GitHub-noden på PR-händelsen ”synchronize”, så du får validering vid varje ändring, inte bara när PR:en öppnas.
Ditt repo och dina sökvägar sätts en gång. Ett konfigurationssteg samlar saker som repo-URL, manifestPath (AndroidManifest.xml, Info.plist eller liknande), scriptPath och en timeout så körningen inte hänger för evigt.
Validatorn körs i en riktig miljö. Execute Command klonar PR-branchen och kör ditt hjälpskript som startar en emulator/simulator, försöker öppna varje URI och loggar OK/FAIL-utdata. Det är ”CI-vänligt” eftersom skriptet är språkagnostiskt och ligger i ditt repo, vilket gör det enkelt att versionshantera och granska.
Resultaten går tillbaka till PR:en som en tabell. Ett funktionssteg omvandlar kommandoutdata till en Markdown-matris, och sedan postar (eller lägger till) GitHub-noden tabellen som en PR-kommentar så granskare kan skumma den på några sekunder.
Du kan enkelt ändra manifestPath för att validera en annan fil, eller ändra kommentarbeteende (lägg till vs. ersätt senaste) utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-implementeringsguide
Steg 1: Konfigurera webhook-triggern
Konfigurera den inkommande webhooken som tar emot PR-data och startar valideringsprocessen.
- Lägg till noden PR Webhook Trigger.
- Ställ in Path på
validate-pr. - Ställ in HTTP Method på
POST. - Ställ in Response Mode på
lastNodeför att returnera slutresultatet.
Steg 2: Anslut GitHub
Förbered PR-metadata och anslut GitHub för att kunna kommentera.
- Lägg till noden Setup Parameters direkt efter PR Webhook Trigger.
- Ställ in pullRequestNumber på
1(ersätt detta med dynamisk data från er webhook-payload vid behov). - Ställ in repoUrl på repositoryts clone-URL (lämna tomt om ni planerar att mappa detta från webhook-payloaden).
- Ställ in manifestPath på
deeplink-validator-demo/AndroidManifest.xml. - Ställ in scriptPath på
deeplink-validator-demo/validate-links.sh. - Ställ in branchName på
main. - Ställ in repositoryFullName på
reponamei formatetowner/repo. - Öppna Post GitHub Comment och ställ in Credential Required: anslut era
githubApi-uppgifter.
owner/repo kommer de uttrycksbaserade fälten owner och repository att tolkas fel.Steg 3: Sätt upp körning och parsning för validering
Kör valideringsskriptet och omvandla dess output till en markdown-tabell.
- Lägg till Execute Validation Shell efter Setup Parameters.
- Ställ in Command på det tillhandahållna shell-skriptet och behåll uttrycken intakta:
=#!/bin/sh rm -rf /tmp/validation echo "🔄 Cloning repo: {{ $json.repoUrl }}" git clone --depth 1 --branch "{{ $json.branchName }}" "{{ $json.repoUrl }}" /tmp/validation || exit 1 SCRIPT_PATH="/tmp/validation/{{ $json.scriptPath }}" MANIFEST_PATH="/tmp/validation/{{ $json.manifestPath }}" echo "📁 Validating script path:" ls -l "$SCRIPT_PATH" || exit 1 chmod +x "$SCRIPT_PATH" || exit 1 echo "🚀 Executing: $SCRIPT_PATH $MANIFEST_PATH" sh "$SCRIPT_PATH" "$MANIFEST_PATH" || { echo "❌ Script execution failed" exit 1 } echo "✅ Script ran successfully". - Lägg till Build Markdown Table efter Execute Validation Shell.
- Ställ in functionCode på den tillhandahållna JavaScript-koden som parsar
stdouttillmarkdownResult.
Steg 4: Konfigurera output till GitHub
Publicera markdown-resultaten som en kommentar på den aktuella pull requesten.
- Lägg till Post GitHub Comment efter Build Markdown Table.
- Ställ in Operation på
createComment. - Ställ in Body på
={{ $json.markdownResult }}. - Ställ in Owner på
={{ $('Setup Parameters').item.json.repositoryFullName.split("/")[0] }}. - Ställ in Repository på
={{ $('Setup Parameters').item.json.repositoryFullName.split("/")[1] }}. - Ställ in Issue Number på
={{ $('Setup Parameters').item.json.pullRequestNumber }}.
Steg 5: Testa och aktivera ert workflow
Kör ett fullständigt test med en exempel-payload för PR och aktivera sedan workflowet.
- Klicka på Execute Workflow och skicka en POST-begäran till PR Webhook Trigger-test-URL:en med giltig PR-data.
- Bekräfta att Execute Validation Shell skriver ut valideringsresultat till
stdout. - Verifiera att Build Markdown Table skapar en markdown-tabell i
markdownResult. - Kontrollera att Post GitHub Comment publicerar en kommentar på angiven PR.
- Slå om workflowet till Active för att aktivera användning i produktion.
Vanliga fallgropar
- GitHub-credentials kan gå ut eller behöva specifika behörigheter. Om det slutar fungera: kontrollera först token-scopes (repo eller public_repo) och n8n:s GitHub-credential.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du redigera utdata för alltid.
Vanliga frågor
Cirka 30–60 minuter när din GitHub-token och runner är redo.
Nej, inte på n8n-sidan. Du behöver däremot ett litet shell-skript (ofta kopierat och justerat) för att validera dina länkar.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in kostnaden för din CI/runner (och eventuella Android/iOS-emulatorimages du använder).
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger dig obegränsade exekveringar men kräver grundläggande serverdrift.
Ja. De flesta team duplicerar Execute Command-körningen för varje manifest (AndroidManifest.xml och Info.plist) och slår sedan ihop de två resultatuppsättningarna före steget med Markdown-tabellen. Du kan också bygga ut skriptet så att det tar en lista med manifestsökvägar och skriver ut en sammanslagen CSV, vilket håller n8n enklare.
Oftast beror det på en utgången eller för snålt scopad Personal Access Token. Skapa en ny PAT med repo-scope (eller public_repo), uppdatera credential i n8n och kör workflowet igen på en ny PR-push. Om det fortfarande misslyckas: kontrollera om repot ligger i en org som kräver SSO-auktorisering för tokens. Rate limits kan också ställa till det om du kommenterar på många PR:er snabbt, så håll workflowet begränsat till de repos som faktiskt behöver det.
På n8n Cloud Starter brukar det räcka gott för ett litet teams dagliga PR-volym, och högre planer klarar mer. Om du self-hostar är exekveringar inte begränsade, så din flaskhals blir runner-kapacitet och emulatorns starttid. I praktiken kör team ofta detta på varje PR-push och det förblir stabilt så länge valideringsskriptet har en rimlig timeout.
För deep-link-validering, ja, eftersom du behöver en riktig command runner för att klona repos och starta emulatorer, inte bara ”koppla app A till app B”. n8n gör det också enklare att hålla allt i ett och samma workflow, inklusive att omvandla utdata till en Markdown-tabell. Zapier/Make kan trigga på GitHub-händelser, men de passar sämre för att köra och hantera CI-liknande skript. Om du vill kan du prata med en automationsexpert, så säger vi snabbt vad som är enklast för din setup.
När detta väl rullar slutar deep-link-validering vara ”nice-to-have” och blir en del av den normala PR-rytmen. Workflowet gör de repetitiva kontrollerna så att teamet kan fokusera på själva kodgranskningen.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.