PR-granskningar är där bra releaser går för att dö. Inte för att folk inte bryr sig, utan för att den “snabba kontrollen” blir en halvtimmes kontextbyte, och samma kommentarer skrivs om och om igen.
Den här automatiseringen för GitHub PR-granskningar slår hårdast mot engineering leads, men byråägare som levererar kundarbete och produktteam som rör sig snabbt känner av den också. Du får konsekventa, lättlästa granskningsanteckningar på varje pull request, med en tydlig etikett “Reviewed by AI” så att inget faller mellan stolarna.
Nedan ser du hur arbetsflödet körs i n8n, vad det producerar på en riktig PR och vad du behöver för att rulla ut det utan att göra ditt repo till ett experiment.
Så fungerar automatiseringen
Hela n8n-arbetsflödet, från trigger till slutresultat:
n8n Workflow Template: GitHub + OpenAI: enhetliga PR-granskningar
flowchart LR
subgraph sg0["PR Flow"]
direction LR
n0@{ icon: "mdi:brain", form: "rounded", label: "OpenAI Chat Model", pos: "b", h: 48 }
n1["<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/>PR Trigger"]
n2["<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/httprequest.dark.svg' width='40' height='40' /></div><br/>Get file's Diffs from PR"]
n3["<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/code.svg' width='40' height='40' /></div><br/>Create target Prompt from PR.."]
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 Robot"]
n5["<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/>Add Label to PR"]
n6@{ icon: "mdi:database", form: "rounded", label: "Code Best Practices", pos: "b", h: 48 }
n7@{ icon: "mdi:robot", form: "rounded", label: "Code Review Agent", pos: "b", h: 48 }
n1 --> n2
n4 --> n5
n7 --> n4
n0 -.-> n7
n6 -.-> n7
n2 --> n3
n3 --> n7
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 n1 trigger
class n7 ai
class n0 aiModel
class n6 database
class n2 api
class n3 code
classDef customIcon fill:none,stroke:none
class n1,n2,n3,n4,n5 customIcon
Problemet: PR-granskningar är inkonsekventa och långsamma
Manuell PR-granskning är en av de processer som ser bra ut på papper, men som i det tysta äter upp din vecka. Någon öppnar en pull request, du skummar diffen, lämnar några noteringar och upprepar sedan samma checklista för “namngivning, felhantering, tester, edge cases” för tionde gången. Under tiden väntar författaren, branchen blir inaktuell och nästa PR staplas på. Värst är inkonsekvensen. En granskare bryr sig om loggning, en annan om stil, och teamet lär sig att behandla feedback som subjektivt brus istället för en pålitlig ribba.
Det blir snabbt mycket. Här är var det faller isär i vardagen.
- Granskningar blir försenade eftersom de kräver djupt fokus, och djupt fokus är alltid uppbokat.
- Vanlig feedback upprepas mellan PR:er, så seniora utvecklare lägger tid på att skriva om regler istället för att lösa svårare problem.
- Viktiga problem slinker igenom när granskare är trötta, stressade eller ovana vid en del av kodbasen.
- Nyare utvecklare får ojämn vägledning, vilket saktar ner onboarding och skapar “dolda standarder” som ingen kan sätta ord på.
Lösningen: OpenAI granskar varje ny PR och postar en märkt kommentar
Det här arbetsflödet gör pull request-granskning till ett konsekvent, repeterbart system. Det startar i samma ögonblick som en ny PR skapas i GitHub. n8n hämtar listan över ändrade filer och tar hem koddiffarna, och bygger sedan en granskningsprompt som inkluderar både ändringarna och era interna best practices. Dessa best practices kan ligga i ett Google Sheet, vilket är en riktigt bra plats eftersom icke-utvecklare kan uppdatera reglerna utan att röra arbetsflödet. En OpenAI-driven agent läser diffen, kontrollerar den mot era riktlinjer och genererar tydliga granskningsnoteringar. Till sist postar arbetsflödet granskningen direkt tillbaka till PR:en som en kommentar och lägger på en synlig etikett “Reviewed by AI” så att teamet snabbt kan triagera.
Arbetsflödet startar på en GitHub pull request-trigger. Därifrån hämtar det PR-diffar, berikar kontexten via ett riktlinje-ark och ber AI-agenten att ta fram granskningsfeedback på klarspråk. I slutet får GitHub två uppdateringar: en kommentar och en etikett.
Det du får: automatisering vs. resultat
| Vad arbetsflödet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att ditt team levererar 15 PR:er i veckan. En snabb mänsklig granskning är sällan “snabb”; även 20 minuter per PR är cirka 5 timmar i veckan, och det är innan följdkommentarer. Med det här arbetsflödet öppnar författaren PR:en och inom några minuter finns en tydlig AI-granskningskommentar plus etiketten “Reviewed by AI”. Någon gör fortfarande den slutliga mänskliga signeringen, men de börjar från en tajtare baseline, inte från ett blankt blad. Det är några timmar tillbaka varje vecka, 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 PR-triggers, kommentarer och etiketter
- OpenAI för att generera granskningsfeedbacken
- OpenAI API-nyckel (hämta den i OpenAI API-dashboarden)
Kunskapsnivå: Medel. Du kopplar in inloggningar, väljer repos och justerar en prompt, men du behöver inte skriva applikationskod.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så funkar det
En ny pull request startar allt. GitHub-triggern bevakar ditt repo efter händelser när PR:er skapas, så arbetsflödet körs så fort en PR dyker upp.
Arbetsflödet samlar in de faktiska ändringarna. n8n hämtar PR:ens fildiffar via en HTTP-request och omformar sedan datan så att AI:n ser en strukturerad, lättläst sammanfattning av vad som ändrats (inte en rörig klump).
Era interna standarder hämtas in. Om ni underhåller best practices i Google Sheets slår arbetsflödet upp dem och lägger till dem i granskningskontexten så att feedbacken matchar hur ni vill att kod ska skrivas.
AI:n genererar feedback och GitHub uppdateras. OpenAI:s chatmodell driver en agent som fungerar som en “code review assistant” och tar fram strukturerade granskningsnoteringar, som postas tillbaka till PR:en som en kommentar. Därefter lägger arbetsflödet på etiketten “Reviewed by AI” för att göra statusen synlig i PR-listan.
Du kan enkelt ändra källan för riktlinjerna till ett annat dokument eller en databas beroende på behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera pull request-triggern
Konfigurera GitHub-triggern så att arbetsflödet startar varje gång en pull request-händelse inträffar i ert repo.
- Lägg till och öppna Pull Request Trigger.
- Ställ in Authentication på
oAuth2. - Välj er GitHub Owner och Repository från listfälten.
- Ställ in Events på
pull_request. - Inloggningsuppgift krävs: Anslut era
githubOAuth2Api-inloggningsuppgifter.
Steg 2: Anslut hämtning av GitHub-data
Hämta fil-diffar från pull requesten för att ge innehållet som behövs för granskningsprompten.
- Lägg till Fetch PR File Diffs och anslut den efter Pull Request Trigger.
- Ställ in URL till
=https://api.github.com/repos/{{$json.body.sender.login}}/{{$json.body.repository.name}}/pulls/{{$json.body.number}}/files. - Låt Options vara standard om ni inte behöver anpassade headers.
Steg 3: Sätt upp granskningsprompten och AI-agenten
Bygg prompten från diffarna och konfigurera AI-agenten med OpenAI-modellen och ett valfritt verktyg för riktlinjer.
- Lägg till Assemble Review Prompt och anslut den efter Fetch PR File Diffs.
- Behåll den angivna JavaScript Code för att generera
user_messagefrån filpatchar. - Lägg till Code Review Assistant och anslut den efter Assemble Review Prompt.
- Ställ in Text till
{{ $json.user_message }}och behåll Prompt Type somdefine. - Öppna OpenAI Chat Engine och välj modellen
gpt-4o-mini. - Inloggningsuppgift krävs: Anslut era
openAiApi-inloggningsuppgifter i OpenAI Chat Engine. - Öppna Guidelines Sheet Lookup och ange Document ID och Sheet Name till er källa för granskningsregler.
- Inloggningsuppgift krävs: Anslut era
googleSheetsOAuth2Api-inloggningsuppgifter. Det här verktyget är kopplat till Code Review Assistant, så säkerställ att inloggningsuppgifterna är tillgängliga för den överordnade agentanslutningen.
Steg 4: Konfigurera åtgärder för granskningsutdata
Skicka den AI-genererade granskningen som en GitHub-granskningskommentar och applicera en etikett på pull requesten.
- Lägg till Post Review Comment och anslut den efter Code Review Assistant.
- Ställ in Resource på
reviewoch Event påcomment. - Ställ in Body till
{{ $json.output }}. - Ställ in Pull Request Number till
{{ $('Pull Request Trigger').first().json.body.number }}. - Inloggningsuppgift krävs: Anslut era
githubApi-inloggningsuppgifter. - Lägg till Apply Review Label och anslut den efter Post Review Comment.
- Ställ in Operation på
editoch Authentication påoAuth2. - Under Edit Fields → Labels, lägg till
ReviewedByAI. - Ställ in Issue Number till
{{ $('Pull Request Trigger').first().json.body.number }}. - Inloggningsuppgift krävs: Anslut era
githubOAuth2Api-inloggningsuppgifter.
$json.output. Säkerställ att agenten returnerar utdatatext, annars blir granskningen tom.Steg 5: Testa och aktivera ert arbetsflöde
Verifiera arbetsflödets beteende med en riktig pull request och aktivera det sedan för produktionsanvändning.
- Klicka på Execute Workflow och trigga en pull request-händelse i ert GitHub-repo.
- Bekräfta att Fetch PR File Diffs returnerar fildata och att Assemble Review Prompt skapar ett
user_message. - Kontrollera att Post Review Comment lägger till en granskningskommentar och att Apply Review Label lägger till
ReviewedByAI. - Om alla steg lyckas, växla arbetsflödet till Active för kontinuerlig användning.
Vanliga fallgropar
- GitHub-inloggningar kan gå ut eller kräva specifika behörigheter. Om det skapar fel, kontrollera sidan Credentials i n8n och bekräfta att din token kan läsa PR:er och skapa PR-kommentarer.
- Om du använder Wait-noder eller extern rendering varierar processingtider. Ö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 att redigera utdata för alltid.
Vanliga frågor
Cirka en timme om dina GitHub- och OpenAI-inloggningar är klara.
Nej. Du kopplar konton och justerar några fält i n8n. Den enda “kodlika” delen är att redigera granskningsprompten på enkel svenska.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer startar på 20 USD/månad för högre volym. Du behöver också räkna in OpenAI API-kostnader, som vanligtvis är några cent per granskning beroende på diffens storlek.
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 körningar men kräver grundläggande serverhantering.
Ja, men du behöver göra det med avsikt. De flesta team skapar ett arbetsflöde per repo (eller per språk) och pekar “Guidelines Sheet Lookup” mot rätt flik i Google Sheets. Du kan också skicka in reponamnet i prompten och ladda olika riktlinjerader baserat på det värdet. Vanliga justeringar är att ändra tonläget i feedbacken, kräva viss testtäckning och lägga till “säkerhetskontroller” som granskare ofta glömmer.
Oftast handlar det om utgångna inloggningar eller saknade scopes i din GitHub OAuth-app eller PAT. Uppdatera inloggningen i n8n och bekräfta sedan att token kan läsa pull requests, läsa filer och skapa PR-kommentarer. Om kommentering fungerar men etikettering misslyckas, kontrollera att repot tillåter att token hanterar etiketter och att etikettnamnet matchar exakt. Rate limiting kan också dyka upp om du kör detta över många repos samtidigt, så att glesa ut körningarna kan hjälpa.
Många, så länge dina exekveringsgränser och din OpenAI-budget matchar volymen. På n8n Cloud beror din månatliga exekveringsgräns på planen; self-hosting tar bort plattformsgränsen och flyttar begränsningen till din serverkapacitet. I praktiken är flaskhalsen oftast API-rate limits eller väldigt stora diffar, inte n8n i sig.
Ofta, ja. Det här arbetsflödet drar nytta av n8n:s förgreningar och agentliknande logik, plus möjligheten att self-hosta när PR-volymen växer. Zapier eller Make kan fortfarande fungera, men du kan slå i taket när du börjar loopa igenom filer, slå ihop kontext och styra formatering. Du vill också sannolikt ha tajtare kontroll över vad som skickas till modellen, vilket är enklare när du kan redigera steget som bygger prompten. Om du är osäker, prata med en automationsexpert så mappar vi det mot din repo-volym och granskningsprocess.
Konsekvent PR-feedback ska inte bero på vem som har tid den dagen. Sätt upp det här en gång, så får varje pull request en tydlig förstagranskning du kan lita på.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.