Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
januari 22, 2026

GitHub till Gmail, kuraterat nyhetsbrev om issues

Rickard Andersson Partner, Nodenordic.se

Du öppnar GitHub för att ”bara kolla issues”, och plötsligt sitter du med 40 flikar, läser halvfärdiga trådar och tappar bort den enda saken du faktiskt behövde agera på. Det är rörigt, och de bra nybörjarvänliga uppgifterna begravs.

Den här GitHub Gmail-nyhetsbrev-automationen träffar marknadsansvariga som driver utvecklarcommunityn, men byråägare och produktteam som följer open source-beroenden känner av det också. I stället för att skanna i all oändlighet får du ett kort, kurerat mejl med upp till tre issues som faktiskt är värda din tid.

Nedan ser du hur workflowet hittar issues, ber AI att ranka dem utifrån ”bidragsvänlighet”, hämtar praktisk vägledning för hur du bidrar och sedan levererar ett snyggt Gmail-nyhetsbrev som du kan läsa på två minuter.

Så här fungerar automationen

Se hur detta löser problemet:

n8n Workflow Template: GitHub till Gmail, kuraterat nyhetsbrev om issues

Utmaningen: att göra GitHub-brus till handling

De flesta repo:n har gott om etiketter som ”good first issue”, men det betyder inte att de är bra. Vissa är inaktuella. Vissa är blockerade av saknad kontext. Andra ser enkla ut tills du upptäcker tre breaking changes och en lång debatt nedgrävd i kommentarerna. Om du försöker bygga en stabil vana att bidra (eller guida ett team att göra det) är den svåraste delen inte motivation. Det är att hitta rätt sak att jobba på utan att lägga hela lunchrasten på triage.

Och friktionen växer.

  • Du slutar med att skumma igenom dussintals issues bara för att välja en som inte är en återvändsgränd.
  • Viktig kontext finns i kommentarer och commits, så en ”snabb koll” blir djup research.
  • Bra möjligheter passerar förbi eftersom du bara kollar när du kommer ihåg, inte med en pålitlig kadens.
  • Även efter att du valt en issue behöver du fortfarande vägledning för ”vad gör jag härnäst?” för att undvika att köra fast.

Lösningen: GitHub-issues kurerade till ett Gmail-nyhetsbrev

Det här workflowet förvandlar en stökig GitHub-surfning till ett strukturerat, repeterbart nyhetsbrev som du faktiskt kan använda. Det börjar med att hämta de senaste repo-detaljerna och aktiva issues via GitHub API (inklusive viktiga signaler som senaste kommentarer och aktivitet). Sedan rankar en AI-agent listan och väljer upp till tre issues som sannolikt är ”nybörjarvänliga”, baserat på kriterier du kan justera. Därefter anropas Deepwiki (via ett MCP-verktyg) för att generera kort, praktisk vägledning för varje issue, så att du får relevans och nästa steg i stället för en vag sammanfattning. Till sist konverteras allt till ett formaterat HTML-mejl och skickas till din Gmail-inkorg med ett applösenord. Ställ in en gång, läs och agera.

Flödet börjar med en trigger (manuell för test, sedan schema). Därefter samlas GitHub-data in, filtreras och poängsätts av AI. Workflowet avslutas med att bygga en MJML-mejllayout, rendera den till HTML och skicka den via Gmail.

Vad som förändras: före vs. efter

Effekt i verkligheten

Säg att du vill bidra till två repo:n varje vecka. Manuellt är det lätt att lägga runt 30 minuter per repo på att skumma issues, och sedan ytterligare 30 minuter på att gräva i kommentarer för att se vad som är görbart, alltså cirka 2 timmar i veckan innan du ens börjar koda. Med det här workflowet schemalägger du en körning, läser ett nyhetsbrev med tre utvalda issues och klickar bara vidare på det som rankats högst. ”Urvalsjobbet” sjunker till cirka 10 minuter, och du får tillbaka kvällarna.

Krav

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
  • GitHub för att hämta issues via API:t.
  • Gmail för att skicka nyhetsbrevet till din inkorg.
  • GitHub Personal Access Token (skapa i GitHub Developer Settings).
  • OpenRouter API-nyckel (hämta i din OpenRouter-dashboard).
  • Google applösenord (skapa i säkerhetsinställningarna för ditt Google-konto).

Kompetensnivå: Mellan. Du klistrar in nycklar, redigerar en repo-konfigurationsnod och testkör tills mejlet ser rätt ut.

Behöver du hjälp att implementera detta? Prata med en automationsexpert (gratis 15-minuters konsultation).

Workflow-flödet

En trigger sätter igång. Du kan köra manuellt när du sätter upp det och sedan byta till en Schedule Trigger så att det landar i inkorgen varje vecka (eller dagligen, om du är ambitiös).

GitHub genomsöks efter verklig aktivitet. Workflowet hämtar repo-detaljer och tar in issues via GitHub API, och delar sedan upp dem i enskilda objekt så att varje issue kan utvärderas på egna meriter.

AI rankar och berikar toppvalen. En agent väljer upp till tre bidragsvänliga issues, och sedan frågas Deepwiki för att generera en kort sammanfattning plus praktisk vägledning (vad du ska ändra, var du ska titta och varför det är viktigt).

Ett färdigt nyhetsbrev sätts ihop och levereras. Workflowet bygger en MJML-layout, renderar den till HTML och skickar den via noden Send Email till Gmail så att det läser som ett riktigt nyhetsbrev, inte en inklistrad loggdump.

Du kan enkelt justera kriterierna för ”bidragsvänlig” så att de matchar teamets nivå eller föredragna teknikstack. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: Konfigurera den manuella triggern

Det här arbetsflödet startas manuellt så att ni kan testa hela nyhetsbrevsflödet från början till slut innan ni aktiverar det i produktion.

  1. Lägg till Manual Start Trigger på arbetsytan som startpunkt.
  2. Koppla Manual Start Trigger till Fetch Repo Details.

Steg 2: Koppla in hämtning av GitHub-data

Definiera repositoryt och hämta issues/releases från GitHub för analys.

  1. I Fetch Repo Details ställer ni in JavaScript Code till return { owner: "fastapi", name: "fastapi" }.
  2. Öppna Retrieve GitHub Issues och ställ in Endpoint till https://api.github.com/graphql.
  3. Ställ in Query till det medföljande GraphQL-uttrycket (behåll de mallade owner/name-värdena i queryn).
  4. Inloggningsuppgifter krävs: Anslut era httpHeaderAuth-uppgifter i Retrieve GitHub Issues.
  5. Koppla Retrieve GitHub Issues till Conditional Check.

Conditional Check routar till OpenRouter API Call endast när repositorydatan finns.

Steg 3: Konfigurera modellval i OpenRouter

Det här avsnittet hämtar gratis modeller och tilldelar dem för rankning, parsning och titelgenerering.

  1. I OpenRouter API Call ställer ni in URL till https://openrouter.ai/api/v1/models.
  2. Säkerställ att Query Parameters inkluderar supported_parameters med värdet response_format.
  3. Inloggningsuppgifter krävs: Anslut era openRouterApi-uppgifter i OpenRouter API Call.
  4. Konfigurera Select Free Models med den medföljande koden för att mappa gratis modell-ID:n till nycklar som issueRankMainModel och deepwikiParserModel.
  5. Koppla OpenRouter API CallSelect Free ModelsIssue Ranking Agent.

⚠️ Vanlig fallgrop: Om Select Free Models returnerar en tom lista kan OpenRouter API-nyckeln sakna åtkomst eller så misslyckades API-anropet—verifiera inloggningsuppgifter och svarsdata.

Steg 4: Sätt upp AI-rankning, parsning och Deepwiki-berikning

Använd AI-agenterna för att ranka issues, parsa strukturerad output och berika varje issue med Deepwiki-vägledning.

  1. I Issue Ranking Agent behåller ni prompt-texten och systemmeddelandet som konfigurerat, inklusive expressions-referenserna till Retrieve GitHub Issues.
  2. Koppla språkmodeller till Issue Ranking Agent: Ranking Primary Model och Ranking Fallback Model med Model satt till {{ $('Select Free Models').item.json.issueRankMainModel }} respektive {{ $('Select Free Models').item.json.issueRankFallbackModel }}.
  3. Koppla den strukturerade parsern Rank Output Parser till Issue Ranking Agent. Parser-schemat är redan definierat i Rank Output Parser.
  4. Inloggningsuppgifter krävs: Anslut era openRouterApi-uppgifter till alla OpenRouter-språkmodellnoder (Ranking Primary Model, Ranking Fallback Model, Rank Parser Model, Deepwiki Primary Model, Deepwiki Backup Model, Deepwiki Parse Model, Title Primary Model, Title Backup Model).
  5. Konfigurera Deepwiki Guidance Agent med dess prompt och systemmeddelande; den använder {{ $json.issueURL }}, {{ $json.issueTitle }} och {{ $json.issueDescription }}.
  6. Säkerställ att Deepwiki MCP Tool är kopplat som ett verktyg till Deepwiki Guidance Agent; lägg till inloggningsuppgifter på den överordnade Deepwiki Guidance Agent om det krävs av er MCP-konfiguration.
  7. Koppla Deepwiki Output Parser och dess modell Deepwiki Parse Model för att parsa det strukturerade svaret.

Split Issue Items skickar output till både Deepwiki Guidance Agent och Combine Issue Data parallellt, vilket berikar varje issue samtidigt som basdatan bevaras.

Steg 5: Konfigurera titelgenerering och datasammanslagning

Generera en nyhetsbrevstitel från den bästa issuet och slå samman all issue-data för layoutrendering.

  1. I Select Best Issues behåller ni koden som sorterar efter lämplighet och tar ut de tre främsta issues.
  2. Select Best Issues skickar output till både Split Issue Items och Newsletter Title Agent parallellt.
  3. Konfigurera Newsletter Title Agent så att den använder issue-sample-expression {{ $json.issues[0].toJsonString() }}.
  4. Koppla Title Primary Model och Title Backup Model till Newsletter Title Agent med modeller satta till {{ $('Select Free Models').item.json.titleGeneratorMainModel }} och {{ $('Select Free Models').item.json.titleGeneratorFallbackModel }}.
  5. Koppla Combine Issue Data till Merge Title Data, och Newsletter Title Agent till Merge Title Data.
  6. I Merge Title Data bekräftar ni att Mode är combine och att Combine By är combineByPosition.

⚠️ Vanlig fallgrop: Om merge-resultatet är tomt, säkerställ att både Combine Issue Data och Newsletter Title Agent skickar ut items (sammanslagningen kombinerar efter position).

Steg 6: Bygg och rendera MJML-nyhetsbrevet

Använd kodnoder för att sätta ihop MJML-markup och rendera den till HTML för e-postleverans.

  1. I Build MJML Layout behåller ni MJML-mallkoden som refererar till Issue Ranking Agent och Combine Issue Data.
  2. Verifiera bild-URL:en och MJML-strukturen i Build MJML Layout (t.ex. https://lh3.googleusercontent.com/d/1VYyXuiNQOnHCBELXh4_6ZDEoL30x7OQk).
  3. Koppla Merge Title DataBuild MJML LayoutRender MJML HTML.
  4. I Render MJML HTML behåller ni koden som konverterar MJML till HTML med mjml2html($input.first().json.issueHTML).

Steg 7: Konfigurera e-postleverans

Skicka det renderade HTML-nyhetsbrevet via SMTP.

  1. Öppna Dispatch Email och ställ in HTML till {{ $('Render MJML HTML').item.json.htmlOutput.html }}.
  2. Ställ in Subject till [Issue Report] {{ $('Fetch Repo Details').item.json.owner }}/{{ $('Fetch Repo Details').item.json.name }} - {{ $('Newsletter Title Agent').item.json.output }}.
  3. Fyll i To Email och From Email med era avsändar-/mottagaradresser.
  4. Inloggningsuppgifter krävs: Anslut era smtp-uppgifter i Dispatch Email.

Steg 8: Testa och aktivera ert arbetsflöde

Kör ett manuellt test för att verifiera datahämtning, parsning av AI-output och e-postleverans innan ni slår på det.

  1. Klicka på Execute WorkflowManual Start Trigger för att köra hela flödet.
  2. Kontrollera Conditional Check för en true-gren och bekräfta att OpenRouter API Call returnerar modeller.
  3. Verifiera att Issue Ranking Agent och Deepwiki Guidance Agent levererar strukturerad data som matchar parserarna.
  4. Bekräfta att Render MJML HTML producerar HTML och att Dispatch Email skickar ett meddelande.
  5. När ni är nöjda, växla arbetsflödet till Active för användning i produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Se upp med

  • Behörigheter för GitHub-token spelar roll. Om ”Retrieve GitHub Issues” plötsligt returnerar tomma resultat, kontrollera token-scopes och bekräfta att den inte har gått ut.
  • Om du kör schemalagt och gör AI-anrop kan processtiden variera. Öka väntetider eller lägg till retries om nedströms parsning misslyckas eftersom ett modellsvar kommer sent.
  • AI-utdata känns generiska tills du finjusterar. Uppdatera kriterierna i IssueRank Agent tidigt, annars kommer du fortsätta tvivla på urvalet och redigera varje mejl.

Vanliga frågor

Hur snabbt kan jag implementera den här GitHub Gmail-nyhetsbrev-automationen?

Cirka 30 minuter om du redan har dina tokens och applösenord redo.

Kan icke-tekniska team implementera den här GitHub Gmail-nyhetsbrev-automationen?

Ja, men du vill ha någon som är bekväm med API-nycklar. Uppställningen är mest copy-paste och testning tills mejlet ser rätt ut.

Är n8n gratis att använda för det här GitHub Gmail-nyhetsbrevs-workflowet?

Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Cloud-planer börjar på $20/månad för högre volym. Du behöver också räkna in OpenRouter API-användning, som beror på vilken modell du väljer.

Var kan jag hosta n8n för att köra den här automationen?

Två alternativ: n8n Cloud (hanterat, enklast uppsättning) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och klarar n8n bra. Egen drift ger dig obegränsade exekveringar men kräver grundläggande serveradministration.

Hur anpassar jag den här GitHub Gmail-nyhetsbrevslösningen till mina specifika utmaningar?

Börja med att redigera steget ”Load repo info” så att det pekar på din owner/repo, och finjustera sedan urvalet i ”Get Top Fit Issues” och kriterierna i IssueRank Agent. Om du hellre vill lyfta ”help wanted” eller ”documentation”-arbete, ändra rankningsprompten så att den prioriterar de etiketterna och nyliga svar från maintainers. Du kan också ändra schemakadensen och höja eller sänka maxantalet issues som utvärderas så att nyhetsbrevet håller sig kort.

Varför fallerar min GitHub-anslutning i det här workflowet?

Oftast är det en utgången eller för snävt scope:ad GitHub Personal Access Token. Skapa en ny token, uppdatera den i credentials för ”Get Issues from GitHub / Retrieve GitHub Issues” och bekräfta att repo:t är åtkomligt för det kontot. Om det bara fallerar på större repo:n kan det vara rate limiting, så minska hur många issues du hämtar eller kör det mer sällan.

Vad är kapaciteten i den här GitHub Gmail-nyhetsbrevslösningen?

Den är byggd för att välja upp till tre issues per körning, så volymen är kontrollerad av design.

Är den här GitHub Gmail-nyhetsbrev-automationen bättre än att använda Zapier eller Make?

För det här workflowet är n8n oftast bättre eftersom det hanterar förgreningslogik, bearbetning item-för-item och AI-berikning i flera steg utan att bli en dyr stapel av tasks. Egen drift tar också bort exekveringsbegränsningar, vilket är smidigt om du senare expanderar från ett repo till många. Zapier eller Make kan fungera om du bara vill ha ”GitHub issues → mejl”, men så fort du lägger till rankning, fallbacks och HTML-rendering blir det pilligt. Ärligt talat är den största skillnaden kontroll: n8n låter dig ändra prompts, parsning och layout på ett ställe. Prata med en automationsexpert om du vill ha hjälp att välja.

När detta väl rullar slutar GitHub vara en oändlig scroll och blir ett kort veckobeslut. Skumma, välj en, bidra, gå vidare.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Launch login modal Launch register modal