Versionsnyheter är lätta att ignorera tills de slår tillbaka. Du hör ”det finns en ny version”, och sedan tappar du 20 minuter på att leta upp ändringsloggen, förstå vad som har ändrats och undra om din instans ligger efter.
Den här automatiseringen för GitHub Gmail releases träffar DevOps-folket först, ärligt talat. Men byråägare som kör kundautomationer och marketing ops-team som lever i n8n känner av samma kaos när uppgraderingar smyger sig på. Resultatet är enkelt: du får ett korrekt formaterat mejl med fullständiga versionsnoteringar, plus vilken version du kör just nu, så att du kan fatta beslut snabbt.
Nedan ser du hur arbetsflödet övervakar ”latest” och ”beta”, avduplicerar nya versioner, hämtar GitHub-noteringar och mejlar allt till Gmail i ett lättläst format.
Så här fungerar automatiseringen
Hela n8n-arbetsflödet, från trigger till slutlig output:
n8n Workflow Template: Från GitHub till Gmail, tydliga release notes
flowchart LR
subgraph sg0["Scheduled Automation Start Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Scheduled Automation Start", pos: "b", h: 48 }
n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "Define n8n URLs & Tags", pos: "b", h: 48 }
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/>Fetch Instance Version"]
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/>Retrieve Latest Release"]
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/httprequest.dark.svg' width='40' height='40' /></div><br/>Retrieve Beta Release"]
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/merge.svg' width='40' height='40' /></div><br/>Combine Version Data"]
n6@{ icon: "mdi:swap-vertical", form: "rounded", label: "Set Version Fields", pos: "b", h: 48 }
n7@{ icon: "mdi:cog", form: "rounded", label: "Remove Duplicate Latest", pos: "b", h: 48 }
n8@{ icon: "mdi:swap-vertical", form: "rounded", label: "Assign Latest Tag Data", pos: "b", h: 48 }
n9@{ icon: "mdi:cog", form: "rounded", label: "Remove Duplicate Beta", pos: "b", h: 48 }
n10@{ icon: "mdi:swap-vertical", form: "rounded", label: "Assign Beta Tag Data", pos: "b", h: 48 }
n11["<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/merge.svg' width='40' height='40' /></div><br/>Merge Release Streams"]
n12["<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 GitHub Notes"]
n13["<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/markdown.dark.svg' width='40' height='40' /></div><br/>Render Notes as HTML"]
n14@{ icon: "mdi:message-outline", form: "rounded", label: "Dispatch Email Alert", pos: "b", h: 48 }
n11 --> n12
n5 --> n6
n0 --> n1
n10 --> n11
n6 --> n9
n6 --> n7
n8 --> n11
n4 --> n5
n2 --> n5
n13 --> n14
n3 --> n5
n12 --> n13
n9 --> n10
n7 --> n8
n1 --> n2
n1 --> n3
n1 --> n4
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 trigger
class n2,n3,n4,n12 api
classDef customIcon fill:none,stroke:none
class n2,n3,n4,n5,n11,n12,n13 customIcon
Problemet: versionsuppdateringar missas (eller upptäcks för sent)
De flesta team ”övervakar” inte releaser på riktigt. De snubblar över dem. Någon nämner en ny n8n-version i Slack, en bugg dyker upp som fixades förra veckan, eller så ska du uppgradera och inser att du inte har läst release notes på månader. Sedan börjar flik-hoppandet: npm för versionstaggar, GitHub för noteringar, din egen instans för att se vad du kör, och tillbaka till GitHub för att se om något som är inkompatibelt är gömt i texten. Det är inte svårt arbete. Det är återkommande arbete, vilket gör det lätt att skjuta upp.
Det summeras snabbt. Och friktionen ökar när du följer både ”latest” och ”beta”.
- Att manuellt kolla npm och GitHub blir en veckoritual som stjäl ungefär en timme du aldrig planerade in.
- Versionsjämförelser blir lätt fel när du jonglerar ”latest”, ”beta” och din nuvarande instansversion.
- Release notes är långa, så folk skummar, missar en rad och blir överraskade vid uppgraderingar.
- Utan en konsekvent avisering blir uppgraderingar reaktiva i stället för planerade, vilket ökar risken för driftstopp.
Lösningen: GitHub → Gmail release notes, automatiskt
Det här arbetsflödet bevakar n8n-releaser enligt ett schema, identifierar vad som är nytt och skickar ett Gmail-meddelande som faktiskt går att läsa. Vid varje körning hämtar det aktuell versionsinfo för ”latest” och ”beta” från npm-registret, kan även kontrollera din egen n8n-instans för att se vilken version du kör, och filtrerar sedan bort allt du redan har blivit aviserad om. Om en ny version hittas hämtar det matchande GitHub release notes, konverterar Markdown till korrekt formaterad HTML och mejlar det till dig som en stylad notis. Du slipper pussla ihop uppdateringar från tre olika ställen.
Arbetsflödet startar med en schemalagd trigger. Det samlar in versionsdata för båda kanalerna, slår ihop och standardiserar den, och avduplicerar sedan så att du bara blir aviserad en gång per version. Till sist hämtar det GitHub-noteringar och skickar ett formaterat Gmail-mejl som innehåller releasenamn, versionstagg, din nuvarande version och fullständiga noteringar.
Det du får: automatisering vs. resultat
| Vad det här arbetsflödet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att du kollar releaser två gånger i veckan. Manuellt öppnar du oftast npm för ”latest” och ”beta” (cirka 10 minuter), öppnar GitHub för noteringar (ytterligare 10 minuter), och loggar sedan in i din n8n-instans eller anropar en endpoint för att bekräfta din nuvarande version (cirka 10 minuter). Det är ungefär 30 minuter per kontroll, alltså cirka 1 timme i veckan. Med det här arbetsflödet är ”arbetet” i princip noll: det körs enligt schema och du skummar ett enda mejl i en minut eller två när något nytt släpps.
Det här behöver du
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
- Gmail för att skicka mejlet med releaseavisering
- GitHub som källa för release notes
- URL till din n8n-instans (ange den i fältet ”my_n8n_url”)
Kunskapsnivå: Nybörjare. Du kopplar Gmail, klistrar in en URL (valfritt) och ändrar ett mottagarfält.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis konsultation i 15 minuter).
Så här fungerar det
Ett schema kontrollerar uppdateringar. Arbetsflödet startar med en schematrigger, så att det kan köras varje timme, dagligen eller i den takt du litar på. Om varje timme känns för brusigt, ändra det.
Versionsinfo hämtas från källorna som spelar roll. Det hämtar versionstaggarna ”latest” och ”beta” från npm-registret via HTTP Request, och kan även fråga din egen n8n-instans-URL för att fånga vilken version du kör just nu.
Bara faktiskt nya releaser går vidare. Arbetsflödet slår ihop strömmarna, normaliserar fält och tar sedan bort dubletter så att du inte får samma avisering vid varje körning. Om det inte finns något nytt, stoppar det.
Release notes hämtas och mejlas i ett läsbart format. För varje ny version hämtar det GitHub release notes, renderar Markdown till HTML och använder sedan Gmail för att skicka en stylad notis med versionstagg, releasenamn, din nuvarande version och fullständiga noteringar.
Du kan enkelt ändra taggarna för releasekanalerna för att bevaka ett annat paket, eller för att ignorera beta helt beroende på dina behov. Se den fullständiga implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera schematriggern
Ställ in automationsfrekvensen så att arbetsflödet kontrollerar nya n8n-releaser med ett regelbundet intervall.
- Lägg till eller öppna Scheduled Automation Start.
- Ställ in intervallfältet Rule till
hours(arbetsflödet är konfigurerat att köra varje timme). - Spara noden för att säkerställa att schemat är aktivt.
Steg 2: Koppla n8n-instans och releasetaggar
Definiera er instans-URL och vilka releasekanaler som ska övervakas.
- Öppna Define n8n URLs & Tags.
- Ställ in my_n8n_url till er instans-URL, till exempel
https://YOUR_n8n_INSTANCE_LINK. - Ställ in n8n_tag_1 till
latestoch n8n_tag_2 tillbeta. - Bekräfta att utdata från Define n8n URLs & Tags är kopplad till noderna som hämtar versioner.
Define n8n URLs & Tags skickar utdata parallellt till Fetch Instance Version, Retrieve Latest Release och Retrieve Beta Release.
https://YOUR_n8n_INSTANCE_LINK oförändrad kommer Fetch Instance Version att misslyckas med ett 404- eller obehörighetsfel.Steg 3: Hämta och kombinera versionsdata
Samla in er nuvarande instansversion och jämför den med latest- och beta-taggarna från npm.
- I Fetch Instance Version ställer ni in URL till
={{ $json.my_n8n_url }}/rest/settings. - I Retrieve Latest Release ställer ni in URL till
=https://registry.npmjs.org/n8n/{{ $json.n8n_tag_1 }}. - I Retrieve Beta Release ställer ni in URL till
=https://registry.npmjs.org/n8n/{{ $json.n8n_tag_2 }}. - Konfigurera Combine Version Data med Mode
combine, Combine BycombineByPositionoch Number Inputs3. - I Set Version Fields mappar ni versioner med uttryck: my_n8n_version =
={{ $json.body_1.data.versionCli }}, n8n_tag1_version =={{ $json.body_2.version }}och n8n_tag2_version =={{ $json.body_3.version }}.
/rest/settings, lägg till nödvändiga autentiseringsalternativ i Fetch Instance Version.Steg 4: Sätt upp routing för releaseströmmar och avduplicering
Förhindra upprepade notiser och paketera data för båda releasekanalerna.
- Öppna Remove Duplicate Latest och ställ in Operation till
removeItemsSeenInPreviousExecutionsoch Dedupe Value till={{ $json.n8n_tag1_version }}. - Öppna Remove Duplicate Beta och ställ in Operation till
removeItemsSeenInPreviousExecutionsoch Dedupe Value till={{ $json.n8n_tag2_version }}. - I Assign Latest Tag Data mappar ni my_n8n_version =
={{ $json.my_n8n_version }}, n8n_tag =={{ $('Define n8n URLs & Tags').item.json.n8n_tag_1 }}och n8n_version =={{ $json.n8n_tag1_version }}. - I Assign Beta Tag Data mappar ni my_n8n_version =
={{ $json.my_n8n_version }}, n8n_tag =={{ $('Define n8n URLs & Tags').item.json.n8n_tag_2 }}och n8n_version =={{ $json.n8n_tag2_version }}. - Verifiera att Merge Release Streams tar emot input från båda noderna för taggtilldelning.
Set Version Fields skickar utdata parallellt till både Remove Duplicate Beta och Remove Duplicate Latest.
Steg 5: Hämta release notes och formatera e-postmeddelandet
Hämta release notes från GitHub och konvertera dem till HTML för e-postens brödtext.
- I Fetch GitHub Notes ställer ni in URL till
=https://api.github.com/repos/n8n-io/n8n/releases/tags/n8n@{{ $json.n8n_version }}. - I Render Notes as HTML ställer ni in Mode till
markdownToHtmloch Markdown till={{ $json.body }}. - Bekräfta att Render Notes as HTML är kopplad till Dispatch Email Alert.
Steg 6: Konfigurera e-postutdata
Skicka den formaterade release-notisen till er inkorg.
- Öppna Dispatch Email Alert.
- Autentiseringsuppgifter krävs: Anslut era gmailOAuth2-uppgifter.
- Ställ in Send To till er e-postadress (ersätt
[YOUR_EMAIL]). - Behåll HTML-mallen för Message som den är för att inkludera release notes, taggar och versionsdetaljer.
- Ställ in Subject till
=⚡ n8n New ({{ $('Merge Release Streams').item.json.n8n_tag }}) Version Released! [{{ $json.name }}].
[YOUR_EMAIL] inte ersätts kommer e-postmeddelandet att misslyckas att skickas eller gå till en ogiltig mottagare.Steg 7: Testa och aktivera ert arbetsflöde
Validera hela flödet och aktivera det sedan för löpande övervakning.
- Klicka på Execute Workflow för att köra automationen manuellt.
- Bekräfta att de parallella grenarna körs: Define n8n URLs & Tags ska trigga Fetch Instance Version, Retrieve Latest Release och Retrieve Beta Release samtidigt.
- Kontrollera att Dispatch Email Alert skickar ett e-postmeddelande som innehåller releaseversionen, taggen och HTML-renderade notes.
- Om utdata är korrekt, växla arbetsflödet till Active för att aktivera schemalagd körning.
Vanliga fallgropar
- Gmail-inloggningsuppgifter kan löpa ut eller kräva rätt Google-behörigheter. Om mejl slutar skickas, kontrollera först det anslutna kontot i Gmail-noden i n8n.
- Om du lägger till Wait-noder senare (eller om GitHub är långsamt) varierar processtiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
- Markdown-till-HTML-resultatet kan se ”konstigt” ut om en release note använder ovanlig formatering. Justera mejlmallen i Gmail-noden så att rubriker och kodblock renderas korrekt.
Vanliga frågor
Cirka 20 minuter om Gmail är redo att kopplas.
Nej. Du kopplar Gmail och ändrar ett par fält i n8n. Logiken är redan byggd.
Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volymer. Du behöver också ta hänsyn till vanliga begränsningar för mejlutskick på ditt Gmail-konto.
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger obegränsade körningar men kräver grundläggande serverhantering.
Ja, men du behöver ändra på två ställen. Uppdatera Set-noden ”Define n8n URLs & Tags” så att den pekar på det paket/tagg du vill ha, och justera sedan HTTP Request-noden för GitHub-noteringar så att den hämtar release notes från rätt repository. Vanliga justeringar är att bara bevaka ”latest”, ändra schemat till dagligen och lägga till en andra notifieringsdestination som Telegram vid sidan av Gmail.
Oftast beror det på utgångna eller återkallade Google-behörigheter. Återanslut Gmail-autentiseringsuppgiften i n8n och bekräfta sedan att Gmail-noden använder rätt konto. Om du är i ett företags Google Workspace kan en adminpolicy också blockera åtkomst. Till sist: kontrollera Gmails sändningsbegränsningar om du testar med många körningar under kort tid.
Många för normal användning, eftersom releaser har låg volym och avdupliceras.
Ofta, ja, eftersom det här arbetsflödet drar nytta av flerstegslogik med förgrening, avduplicering och formatering som är enklare att kontrollera i n8n. Zapier eller Make kan göra ”ny release → mejl”, men du kan behöva bygga på extra steg för parsning, HTML-formatering och för att hantera både latest och beta på ett korrekt sätt. n8n ger dig också ett alternativ för egen drift, vilket spelar roll om du kör många automationer och inte vill ha prissättning per uppgift. Om du redan arbetar i Zapier och bara behöver en enkel ping kan det räcka. Om du vill ha en renare end-to-end-setup, prata med en automationsexpert så visar vi rätt väg.
När detta väl är igång blir releasesynlighet automatiskt. Du får korrekt formaterade noteringar i Gmail, fattar beslutet och går tillbaka till det riktiga jobbet.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.