Gamla GitHub-runners stoppas – version 2.329.0 räcker inte alltid

GitHub började den 29 september 2026 tillämpa versionskraven för egna GitHub Actions-runners i Enterprise Cloud: installationer under 2.329.0 kan inte registreras eller registreras om. Redan anslutna runners kan samtidigt sluta få jobb om de ligger under en separat, högre gräns för körning. En lyckad registrering är därför ingen garanti för att ett arbetsflöde kan starta.

Creutos tekniska genomgång beskriver hur kraven började gälla den 29 september: en runner måste också få varje ny programutgåva inom 30 dagar för att fortsätta ta emot jobb. För ett jobb som väntar i kön är frågan först om en runner alls har registrerats, sedan om den registrerade installationen fortfarande får köra jobb. Ändringen gäller GitHub Enterprise Cloud på github.com. GitHub Enterprise Server omfattas inte av denna verkställighet, och för Enterprise Cloud med Data Residency började den tidigare.

Två gränser ger två olika fel

Registreringsgolvet avgör om GitHub Actions accepterar en ny eller omregistrerad runner. Det är kopplat till den nya arkitektur som tjänsten använder för att kommunicera med runnerprogrammet. En installation som ligger under golvet kommer inte förbi anslutningen, även om samma avbild eller skript fungerade tidigare. Gränsen träffar därför särskilt miljöer som skapar och registrerar en ny instans när arbete ska utföras.

Körningsgränsen avgör i stället om en redan registrerad runner fortfarande är tillräckligt aktuell för att få arbetsflödets jobb. Den följer nya utgåvor och kan därmed flyttas utan att registreringsgolvet ändras. En runner kan synas som registrerad men ändå vara för gammal för att få arbete. Även en uppdatering som precis når registreringsgolvet kan lämna den i det läget, eftersom golvet inte är en permanent godkänd version för körning.

Tidsfristen gäller varje ny runnerutgåva, även mindre uppdateringar. Om programmet inte uppdateras i tid slutar tjänsten köa jobb till den installationen. Vid en kritisk säkerhetsuppdatering kan köningen pausas redan innan den vanliga fristen löper ut. Ett tidigare fungerande arbetsflöde kan alltså börja vänta trots att ingen har ändrat dess konfiguration eller tagit bort runnern från organisationen.

Felsök kön i rätt ordning

Ett köat jobb visar inte ensamt att versionskravet är orsaken. GitHub Actions måste hitta en tillgänglig runner som matchar arbetsflödets etiketter och runnergrupp. Kontrollera därför först vilken grupp och vilka etiketter jobbet begär, och om det finns en ledig, ansluten instans som motsvarar dem. Om ingen sådan instans finns kan jobbet vänta även när alla installerade versioner är aktuella.

När tilldelningen stämmer skiljer registreringsstatus felen åt. Om en nystartad runner aldrig registreras, kontrollera versionen i den avbild eller det installationsskript som just den instansen använder. Om den redan finns i GitHubs lista men jobbet står kvar i kön, jämför dess faktiska version med gränsen för körningsstöd. Att den finns registrerad visar att anslutningen lyckades vid ett tillfälle; det visar inte om installationen fortfarande kan få nya jobb.

För tillfälliga runners kommer registreringsproblemet fram snabbt. De avregistreras efter avslutat jobb och måste registreras när en ny instans skapas. En föråldrad containeravbild eller VM-mall kan då fortsätta skapa maskiner som aldrig får en användbar anslutning. För långlivade instanser syns samma brist på uppdateringar på ett annat sätt: anslutningen består, men nya utgåvor gör så småningom den installerade versionen för gammal för körning.

Uppdateringen måste nå nästa instans

En uppdatering måste nå det runnerprogram som faktiskt startas. Programmet kan uppdatera sig automatiskt om det når GitHubs uppdateringstjänst. I en nätmiljö med begränsad utgående trafik kan den anslutningen därför avgöra om en registrerad runner fortsätter vara aktuell. Där automatisk uppdatering är avstängd behöver organisationen själv föra ut nya programutgåvor.

Det är särskilt viktigt när runners skapas vid behov. En korrigering på en redan körande maskin försvinner om nästa instans kommer från samma gamla mall. För Actions Runner Controller och andra lösningar som använder containeravbilder behöver den underliggande avbilden uppdateras och distribueras, så att även nästa registrering sker med en aktuell version. Det avgörande är vad som finns i underlaget för nästa instans, inte bara vad som tillfälligt finns på en aktiv maskin.

API:t kan varna före nästa körningsstopp

GitHubs REST-dokumentation visar hur organisationens registrerade runners kan listas med version, status och uppgift om huruvida de är tillfälliga. Den beskriver också anropet GET /orgs/{org}/actions/runners/deprecations/{version}, som slår upp när stödet för en viss version upphör. Anropet identifierar inte självt vilka instanser som kör versionen; den uppgiften måste hämtas från listan över registrerade runners.

En automatisk varning kan hämta listan, gruppera instanserna efter version och fråga efter slutdatum för varje förekommande version. Fältet runtime_deprecates_at är relevant för redan registrerade runners som ska ta emot jobb. Svaret kan innehålla enbart datumet för körningsstöd, så ett saknat registreringsdatum behöver hanteras utan att det tolkas som fortsatt stöd. Registreringsgolvet bör samtidigt kontrolleras i de avbilder som ska skapa nya instanser.

När varningen visar att körningsstödet närmar sig slutet blir följden konkret: utan en ny runnerutgåva kan arbetsflödets nästa jobb bli kvar i kön trots att samma runner fortfarande syns som ansluten.

Läs också:

• Ett lyckat agenttest räcker inte – mät utfallet och upprepningen
• GitHub eller GitLab: gratis CI-minuter säger inte hela kostnaden
• Refinyx köper 134 Northvolt-patent – men ska inte driva fabriker