Release-dagen ska inte kännas som arkeologi. Men på något sätt sitter du alltid och gräver i mergade PR:er, gissar vad som faktiskt gick ut och stressar sedan iväg ett Slack-meddelande som missar den enda ändringen någon faktiskt bryr sig om.
Den här automationen för GitHub Slack release slår hårdast mot DevOps-ingenjörer, ärligt talat. Produktorienterade engineering leads känner också av det, liksom tekniska skribenter som dras in i sista minuten. Resultatet är enkelt: utkast till release notes som håller en konsekvent nivå, plus en Slack-uppdatering som är redo att skicka, utan manuell stress i sista stund.
Du får se hur det här n8n-workflowet hämtar mergade PR:er sedan senaste taggen, gör om dem till strukturerade anteckningar, skapar ett utkast till GitHub-release och postar sedan en felfri sammanfattning till Slack.
Så fungerar automationen
Här är hela workflowet du kommer att sätta upp:
n8n Workflow Template: GitHub + Slack: release notes och uppdateringar åt dig
flowchart LR
subgraph sg0["GitHub Release Input Form Flow"]
direction LR
n0@{ icon: "mdi:swap-vertical", form: "rounded", label: "Config", 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/httprequest.dark.svg' width='40' height='40' /></div><br/>Get Latest Git Tag"]
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 Commit Date of Latest Tag"]
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/httprequest.dark.svg' width='40' height='40' /></div><br/>Fetch All Merged PRs Since L.."]
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/code.svg' width='40' height='40' /></div><br/>Adjusted: Group PRs & Genera.."]
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/httprequest.dark.svg' width='40' height='40' /></div><br/>Github Pre Release"]
n6["<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/> Send message to slack"]
n7["<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/form.svg' width='40' height='40' /></div><br/>GitHub Release Input Form"]
n0 --> n1
n1 --> n2
n5 --> n6
n7 --> n0
n2 --> n3
n3 --> n4
n4 --> n5
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 n7 trigger
class n1,n2,n3,n5,n6 api
class n4 code
classDef customIcon fill:none,stroke:none
class n1,n2,n3,n4,n5,n6,n7 customIcon
Varför det här spelar roll: release notes blir alltid en utryckning
De flesta team “skriver inte release notes”. De återskapar dem. Någon öppnar GitHub, filtrerar PR:er, kollar vad som mergats sedan senaste versionstaggen, skummar titlar, klickar in i trådar för kontext och försöker sedan gruppera ändringarna till något som ser medvetet ut. Du kan tappa en timme bara på att lista ut vilka PR:er som hör till releasen, och en timme till på att skriva om råa PR-titlar till något människor kan skanna. Sedan kommer Slack sist, så uppdateringen blir stressad, inkonsekvent eller uteblir. Nästa release upprepar du samma röra.
Friktionen byggs på. Här är var det faller isär för de flesta repos.
- Att hitta “allt sedan senaste taggen” tar längre tid än det borde, särskilt när flera personer har mergat arbete under veckan.
- PR-titlar är inte skrivna som release notes, så samma ändring beskrivs på tre olika sätt beroende på vem som mergade den.
- Om labels inte används konsekvent blir gruppering av ändringar en subjektiv gissningslek och pingpong i kommentarer.
- Slack-annonseringar faller mellan stolarna, så intressenter får reda på ändringar i efterhand (eller inte alls).
Det du bygger: utkast till release notes + en Slack-uppdatering från mergade PR:er
Det här workflowet ger dig en repeterbar release-rutin. Du triggar det manuellt via ett enkelt formulär och anger GitHub-ägare, repository och mål-branch. n8n hämtar sedan den senaste Git-taggen, hittar exakt commit-tid för taggen och använder den som “startlinje” för dina nästa release notes. Därifrån frågar den GitHub efter alla pull requests som mergats efter den tidsstämpeln och organiserar dem i grupperade avsnitt (baserat på PR-labels som du definierar). Till sist skapar den ett utkast till GitHub-release med den senaste taggen och genererad markdown, och postar en formaterad sammanfattning i din Slack-kanal så att hela teamet ser vad som skickas.
Workflowet startar med en snabb formulärinskickning i n8n. GitHub används som sanningskälla för tags och mergade PR:er, och “assemble”-steget gör om PR-data till läsbara anteckningar. I slutet får du ett release-utkast som väntar i GitHub plus ett Slack-meddelande som är redo för människor.
Det du bygger
| Vad som automatiseras | Vad du uppnår |
|---|---|
|
|
Förväntade resultat
Säg att ni releasar varje vecka och att ert repo mergar cirka 25 PR:er mellan taggar. Manuellt är det vanligt att lägga kanske 3 minuter per PR för att hitta den, läsa den och översätta den till release notes-språk, plus ytterligare 20 minuter för att formatera slutposten. Det är ungefär 1,5 till 2 timmar per release. Med det här workflowet lägger du cirka 2 minuter på att fylla i formuläret och sedan några minuter på att granska release-utkastet och Slack-meddelandet innan du skickar. Grovjobbet försvinner till stor del.
Innan du börjar
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- GitHub för taggar, PR-historik och release-utkast
- Slack för att posta release-sammanfattningen till en kanal
- GitHub-token (PAT) eller OAuth (skapa den i GitHub Developer settings)
Nivå: Nybörjare. Du kopplar främst konton, sätter label-regler och testar på ett repository.
Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuterskonsultation).
Steg för steg
Du skickar in release-detaljerna i ett formulär. I n8n anger du repo-ägare, repository-namn och mål-branch (som main). Den manuella triggern är avsiktlig eftersom releaser fortfarande är ett beslut, inte en bakgrundsuppgift.
Workflowet hittar din “startpunkt”. Det hämtar den senaste Git-taggen och hämtar sedan commit-tidsstämpeln för den taggen. Den tidsstämpeln blir brytpunkten så att du bara tar med arbete som mergats efter senaste releasen.
GitHub-PR:er samlas in och görs om till läsbara anteckningar. n8n söker efter mergade pull requests efter bryttiden, och ett kodsteg grupperar PR:er utifrån label-regler som du styr. Det är här stökiga PR-titlar omvandlas till ett strukturerat markdown-utkast.
Resultaten hamnar i GitHub och Slack. Ett utkast till GitHub-release skapas (så att du kan redigera innan publicering), och en formaterad sammanfattning skickas till Slack så att teamet ser höjdpunkterna direkt.
Du kan enkelt justera label-grupperingen och Slack-formateringen efter dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera formulärtriggern
Börja med att konfigurera formulärtriggern som fångar repository-detaljerna som används genom hela arbetsflödet.
- Lägg till noden Release Info Intake Form som din trigger.
- Ställ in Form Title på
GitHub Release Input Form. - Konfigurera tre obligatoriska fält: Repository Name, Repository Owner och Branch Name med de angivna platshållarna.
Steg 2: anslut GitHub
Konfigurera GitHub API-anropen som hämtar taggar och skapar draft-releasen.
- Öppna Fetch Newest Git Tag och ställ in URL på
=https://api.github.com/repos/{{$json["repoOwner"]}}/{{$json["repoName"]}}/tags. - Autentisering krävs: Anslut era githubApi-uppgifter i Fetch Newest Git Tag.
- Autentisering krävs: Anslut era httpHeaderAuth-uppgifter i Fetch Newest Git Tag om er GitHub-konfiguration kräver header-baserad autentisering.
- Öppna Create Draft GitHub Release och ställ in URL på
=https://api.github.com/repos/{{ $('Setup Parameters').first().json.repoOwner }}/{{ $('Setup Parameters').first().json.repoName }}/releases. - Ställ in Method på POST och aktivera Send Body.
- I Body Parameters, ställ in: tag_name till
={{ $('Fetch Newest Git Tag').first().json.name }}, name till={{ $('Fetch Newest Git Tag').first().json.name }}, body till={{ $json.release_notes }}, draft till={{ true }}och prerelease till={{ false }}. - Autentisering krävs: Anslut era httpHeaderAuth-uppgifter i Create Draft GitHub Release.
Steg 3: sätt upp dataförberedelse och bearbetning av release notes
Dessa noder formar indata, hämtar PR:er sedan senaste taggen och sätter ihop brödtexten för release notes.
- I Setup Parameters, ställ in repoOwner till
={{ $json['Repository Owner'] }}, repoName till={{ $json['Repository Name'] }}och defaultBranch till={{ $json['Branch Name'] }}. - I Setup Parameters, ställ in =labelMap till
{ "Feature": "🚀 Features", "bug": "🐞 Bug Fixes", "performance": "⚡ Performance", "sdk": "📦 SDK / Dependency" }. - I Setup Parameters, ställ in =qaChecklist till
[ "[ ] App boots successfully", "[ ] No crash on startup", "[ ] All features tested", "[ ] No broken UI on devices" ]. - Öppna Retrieve Tag Commit Time och ställ in URL på
={{$json["commit"]["url"]}}. - Öppna Collect Merged PRs After Tag och ställ in URL på
=https://api.github.com/search/issues?q=is:pr+is:merged+repo:{{ $('Setup Parameters').first().json.repoOwner }}/{{ $('Setup Parameters').first().json.repoName }}+base:{{ $('Setup Parameters').first().json.defaultBranch }}+merged:>={{ $json.commit.author.date }}. - Lämna koden i Assemble Release Notes oförändrad om ni inte behöver annan gruppering eller annan formatering av QA-checklistan.
Steg 4: konfigurera utdatameddelanden
När draft-releasen har skapats publicerar arbetsflödet en Slack-uppdatering med anteckningarna och release-URL:en.
- Bekräfta ordningen: Assemble Release Notes → Create Draft GitHub Release → Post Slack Update.
- Öppna Post Slack Update och ställ in URL till er Slack inkommande webhook-endpoint.
- Ställ in Method på POST och säkerställ att Send Body är aktiverat.
- Ställ in body-parametern text till
={{ $('Assemble Release Notes').item.json.release_notes }} {{ $json.html_url }}.
Steg 5: testa och aktivera ert arbetsflöde
Verifiera end-to-end-flödet och aktivera det sedan för löpande användning.
- Klicka på Execute Workflow och skicka in formuläret i Release Info Intake Form med ett riktigt repository, ägare och branch.
- Verifiera att Fetch Newest Git Tag returnerar den senaste taggen och att Collect Merged PRs After Tag returnerar PR:er efter den commit-tiden.
- Bekräfta att Create Draft GitHub Release skapar en draft-release med de sammanställda anteckningarna.
- Kontrollera Slack efter meddelandet som publicerats av Post Slack Update och som innehåller release notes samt release-URL:en.
- När allt ser korrekt ut, slå på arbetsflödet till Active för produktionsanvändning.
Felsökningstips
- GitHub-autentisering kan gå ut eller sakna behörigheter. Om PR-sökningen eller skapandet av release-utkast misslyckas, börja med att kontrollera token-scope (du behöver normalt repo-åtkomst, och för att skapa release-utkast krävs skrivbehörighet).
- Om GitHub svarar “inga PR:er hittades” beror det ofta på bryttiden eller branch-namnet. Bekräfta att din senaste tagg finns, pekar på rätt commit och att PR:er faktiskt mergades efter taggens tidsstämpel.
- Slack-meddelanden kan komma fram tomma om fältet för release notes inte skickas vidare. I n8n, inspektera inkommande JSON till Slack-noden och säkerställ att genererad markdown eller sammanfattningstext är korrekt mappad.
Snabba svar
Cirka 30 minuter om din GitHub-token och Slack-åtkomst är redo.
Nej. Du kopplar GitHub och Slack och justerar sedan några inställningar som label-gruppering och meddelandeformat.
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 volymer. Du behöver även räkna in kostnader för GitHub och Slack (oftast 0 USD för API-åtkomst vid normal användning).
Två alternativ: n8n Cloud (hanterat, enklast att sätta upp) 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 serveradministration.
Ja, och det bör du. De flesta team börjar med att redigera label-mappen i noden “Setup Parameters”, justerar sedan markdown-outputen i “Assemble Release Notes” och ändrar till sist Slack-payloaden i “Post Slack Update” så att den matchar kanalens stil.
Oftast beror det på token-scope eller en utgången credential. Skapa en ny GitHub PAT, säkerställ att den har repo-åtkomst och uppdatera sedan den credential som används av HTTP Request/GitHub-stegen i n8n. Om du kör detta i en org kan SSO-krav blockera tokens tills de har auktoriserats. Rate limiting kan också uppstå om du kör det upprepade gånger över flera repos under en kort tidsperiod.
Mer än tillräckligt för normala release-cykler. De flesta team kör det veckovis eller per sprint, och det hanterar utan problem dussintals mergade PR:er i en körning; om du hämtar hundratals, räkna med längre bearbetning och överväg att köra utanför kontorstid.
Ofta, ja, eftersom logiken “sedan senaste taggen” och grupperingsreglerna snabbt blir komplexa. n8n hanterar gärna fler-stegs HTTP-anrop, datatransformering och anpassad gruppering i ett workflow, och du kan self-hosta för obegränsade körningar. Zapier och Make kan fortfarande fungera, men du kan behöva sy ihop flera scenarier, och edge cases i GitHub-sökningar kan bli irriterande. Om du behöver en lättviktig “bara notifiera Slack”-lösning är de verktygen helt okej. Om du är osäker, prata med en automationsexpert så mappar vi det mot er release-process.
När det här väl rullar slutar releaser att vara ett “hoppas att vi inte missade något”-ögonblick. Workflowet sköter insamling och formatering, och du kan fokusera på att leverera (och kommunicera det tydligt).
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.