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

GitHub + Sentry: stoppa merges vid saknade symboler

Rickard Andersson Partner, Nodenordic.se

Dina crashrapporter säger ”osymboliserad”, och alla låtsas att det är okej tills den dag du faktiskt behöver stacktracen. Då gräver du i byggloggar, jagar saknade dSYM- eller mappingfiler och ”snabbfixen” blir en hel eftermiddag.

Den här Sentry merge automation slår mot mobilutvecklare först, men DevOps och release manager känner också av den. I stället för att hoppas att artefakter laddades upp får du en hård grind: inga symboler, ingen grön bock, ingen merge.

Det här arbetsflödet gör fullständigheten i Sentry-artefakter till en GitHub-commitstatus. Du får se hur det stoppar dåliga merges, vad du behöver för att köra det och var team brukar gå på minor.

Så fungerar automatiseringen

Se hur den här löser problemet:

n8n Workflow Template: GitHub + Sentry: stoppa merges vid saknade symboler

Utmaningen: leverera krascher du inte kan felsöka

Saknade symbolfiler är en särskild sorts smärta eftersom du inte märker dem när allt rullar på. De dyker upp efter release, när krascherna ökar, supporten eskalerar och du behöver svar direkt. Utan iOS dSYM-filer eller Android ProGuard/mapping.txt kan Sentry inte översätta minnesadresser till läsbara stacktraces. Då slösar teamet tid på gissningar, på att köra om byggen eller på att försöka ladda upp artefakter i efterhand (vilket ofta är stökigt, ibland omöjligt). Det är inte en stor katastrof. Det är konstant friktion som gör incidenthantering till arkeologi.

Friktionen byggs på. Här är var det faller isär.

  • Artefaktuppladdningar sker ”senare”, vilket innebär att de hoppas över när CI är pressad.
  • En versionsmiss mellan release gör att Sentry ser tomt ut även när bygget producerade rätt filer.
  • Du upptäcker problemet först efter merge, när rollback eller att klippa en ny build kostar timmar.
  • Manuella kontroller är opålitliga eftersom ingen vill klicka runt i Sentry-releaser för varje PR.

Lösningen: verifiera Sentry-symboler vid varje GitHub-push

Det här arbetsflödet fungerar som en kvalitetsgrind för symbolisering. Varje gång kod pushas till GitHub hämtar n8n commit-SHA och letar upp motsvarande release i Sentry. Därefter hämtar det uppladdade releasefiler och kontrollerar ett av två ”bra” lägen: att en iOS .dSYM finns, eller att Android har både proguard.txt och mapping.txt. Om artefakterna finns postar arbetsflödet en commitstatus med ”success” tillbaka till GitHub, vilket syns som en grön bock på commit/PR. Om artefakter saknas postar den inte success, så era merge-regler kan blockera PR:en tills byggpipen har fixat uppladdningen.

Arbetsflödet startar med en GitHub push-händelse. Sedan anropar det Sentry API för att hitta rätt release och lista dess filer, baserat på releaseversionen. Till sist uppdaterar det GitHub commitstatus endast när valideringen godkänns.

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

Effekt i verkligheten

Säg att teamet mergar cirka 10 PR:er i veckan och att ni gör en ”snabb” manuell Sentry-koll som tar kanske 10 minuter per PR (hitta releasen, öppna filer, rimlighetskolla namn). Det är ungefär 2 timmar av rutinjobb, och ändå missar man versionsmismatchar. Med det här arbetsflödet körs kontrollen automatiskt vid varje push: några sekunder för att hämta releaser, några sekunder för att lista filer, och sedan visar GitHub en grön bock (eller inte). Tiden stannar hos teamet, inte i processen.

Krav

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
  • GitHub för push-händelser och commitstatusar
  • Sentry för att verifiera release-artefaktfiler
  • Sentry auth token (skapa den i Sentry-inställningar under API)

Kunskapsnivå: Medel. Du kopplar in credentials och justerar ett par URL:er och valideringsregler, men du behöver inte vara utvecklare på heltid.

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

Flödet i arbetsflödet

En push träffar ditt repo. GitHub-triggern fångar reponamn, branch och commit-SHA så att arbetsflödet vet exakt vilken ändring det utvärderar.

Sentry-releaser hämtas. n8n anropar Sentry API för ditt projekt (med din org_slug och proj_slug) och hittar sedan releasen som matchar den version som din byggpipeline laddade upp.

Artefakter valideras. En liten logikbit kontrollerar listan över releasefiler. iOS godkänns om en .dSYM-fil finns. Android godkänns bara när både proguard.txt och mapping.txt finns. Inga halva poäng.

GitHub får en statusuppdatering. Om artefakterna ser bra ut postar arbetsflödet en commitstatus med ”success”, som dina branch-skydd kan kräva före merge. Om artefakter saknas stannar arbetsflödet och PR:en fortsätter vara blockerad.

Du kan enkelt ändra artefaktreglerna för att kräva extra filer (Unity-symboler, native-moduler, separata staging-byggen) utifrån era behov. Se den fullständiga implementationsguiden nedan för anpassningsalternativ.

Se upp med

  • Sentry-credentials kan gå ut eller kräva specifika behörigheter. Om det strular, kontrollera först scopes på din Sentry-token och n8n:s credential-test.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om noder längre fram fallerar på tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du redigera output i all evighet.

Vanliga frågor

Hur snabbt kan jag implementera den här Sentry merge automation-automatiseringen?

Vanligtvis på cirka 30 minuter när du har tokens klara.

Kan icke-tekniska team implementera den här artefaktgrinden?

Ja, men någon behöver vara bekväm med att skapa API-tokens och klistra in dem i n8n. Efter det är det mest kopiera och redigera Sentry-URL:er och success-meddelandet.

Är n8n gratis att använda för det här Sentry merge automation-arbetsflödet?

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 med Sentry (din plan) och normal GitHub-användning, men det finns ingen avgift per kontroll från Sentrys API vid typiska volymer.

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

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 kör n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serverhantering.

Hur anpassar jag den här Sentry merge automation-lösningen till mina specifika utmaningar?

Du kan ändra valideringsreglerna i kodsteget Verify Artifacts så att de matchar era faktiska artefaktnamn (till exempel acceptera en zippad dSYM som ”.dsym.zip” eller kräva extra native-symboler). Om er release-namngivning skiljer sig åt, justera Sentry-URL:en för release-uppslag i de två HTTP Request-stegen som hämtar releaser och filer. Vanliga anpassningar är att tvinga separata regler per branch (staging vs production), lägga till en Slack-notis när artefakter saknas och spara en loggrad i Airtable för spårbarhet.

Varför misslyckas min Sentry-anslutning i det här arbetsflödet?

Oftast beror det på en ogiltig eller utgången Sentry auth token, så skapa en ny och uppdatera credential i n8n. Näst vanligast är fel org_slug/project_slug i Sentry API-URL:erna, vilket ger tom data eller 404:or. Håll också koll på rate limits om du triggar detta på många pushes under kort tid, och dubbelkolla att release-”versionen” som din pipeline laddar upp matchar vad arbetsflödet förväntar sig.

Vilken kapacitet har den här Sentry merge automation-lösningen?

På en liten n8n Cloud-plan kan de flesta team köra detta på varje push utan att behöva tänka på det.

Är den här Sentry merge automation-automatiseringen bättre än att använda Zapier eller Make?

Ofta, ja, eftersom den här typen av grind behöver villkorslogik, kodbaserad validering och förutsägbar API-hantering. n8n klarar det bra, och du kan self-hosta för att slippa ”per task”-prissättning när push-volymen sticker. Zapier eller Make kan fungera, men du hamnar ofta i kamp med förgreningar och uppslag av releases/filer, och flödet blir snabbt skört. Om du redan använder GitHub branch protections är n8n:s upplägg ”posta bara success när allt är giltigt” enkelt och ärligt talat svårt att slå. Prata med en automationsexpert om du vill ha hjälp att välja.

Det här är en sån automatisering som i tysthet förhindrar dåliga dagar. Sätt upp den en gång, så förblir dina crashrapporter användbara när det verkligen gäller.

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