GitHub Actions börjar stoppa gamla self-hosted runners – bygg en versionsgrind

Nyheten: två stoppdatum för samma version

Den 3 september 2026 presenterade GitHub ett REST-API som anger när en viss Actions runner-version förlorar stöd. GitHubs lanseringsnotis namnger tre svarsfält: runner_version, registration_deprecates_at och runtime_deprecates_at. Endpointen finns på repository-, organisations- och enterprise-nivå.

Skillnaden mellan datumen är driftmässigt viktig. Registreringsstoppet gäller när en runner konfigureras eller återregistreras. Runtimestoppet gäller om den får fortsätta köra workflow-jobb. En redan ansluten maskin kan därför se normal ut samtidigt som en ersättare byggd från samma gamla image inte längre går att registrera. Omvänt är ett godkänt registreringsminimum inte ett löfte om fortsatt jobbkörning.

Brownout gör en frisk flotta opålitlig

I GitHubs enforcement-schema från 12 juni 2026 börjar brownouts med intermittent blockerad registrering och utökas sedan till både registrering och runtime. För GitHub Enterprise Cloud listas en Config-brownout den 7 september, en Config + Runtime-brownout den 9 september och ytterligare en Config-brownout den 11 september. Full enforcement anges börja den 25 september 2026; källan listar dessutom Config + Runtime den 14, 16 och 18 september.

GitHub anger version 2.329.0 som minimum för att konfigurera eller återregistrera mot den nya plattformen. Samma notis säger samtidigt att runtimekravet flyttar sig: varje ny runner-release ska installeras inom 30 dagar. Även en patchrelease räknas. Därför ska du inte hårdkoda 2.329.0 som permanent godkänd version i CI. Fråga endpointen och spara svaret tillsammans med tidpunkten då kontrollen kördes.

Steg 1: samla den faktiska versionsfördelningen

På organisationsnivå ger list-endpointen för self-hosted runners bland annat namn, status, busy-läge och version. Den dokumenterade sidstorleken är högst 100. Följ därför pagineringen i stället för att anta att den första sidan är hela flottan. En fine-grained token behöver organisationsbehörigheten Self-hosted runners: read för just den här listan.

ORG="exempel-ab"
mkdir -p runner-audit

gh api --paginate \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/orgs/$ORG/actions/runners?per_page=100" \
  --jq '.runners[] | [.name, .version, .status, .busy] | @tsv' \
  > runner-audit/runners.tsv

cut -f2 runner-audit/runners.tsv | sort -Vu \
  > runner-audit/versions.txt

Kontrollera att antalet rader motsvarar det du väntar dig och behåll även offline-runners i underlaget. status=online visar anslutning vid hämtningen, inte framtida kompatibilitet. Om autoskalning gör runners kortlivade behöver du dessutom jämföra mot skalsetets image, containerdefinition eller bootstrap-skript; en ögonblickslista kan missa noder som skapas senare.

Steg 2: fråga deprecation-endpointen per version

Följande loop använder organisationsnivån och skriver ett JSON-svar per unik version. Filnamnet gör det möjligt att granska svaret utan att blanda ihop versionerna. En tom eller saknad tidpunkt betyder okänd i underlaget, inte automatiskt godkänd.

while IFS= read -r version; do
  gh api \
    -H "X-GitHub-Api-Version: 2026-03-10" \
    "/orgs/$ORG/actions/runners/deprecations/$version" \
    > "runner-audit/deprecation-$version.json"
done < runner-audit/versions.txt

jq -r '[
  .runner_version,
  (.registration_deprecates_at // "UNKNOWN"),
  (.runtime_deprecates_at // "UNKNOWN")
] | @tsv' runner-audit/deprecation-*.json

Kör inte loopen som en dekorativ dashboardfråga utan som en grind. Spara kontrolltid i UTC, organisation, API-version, versionslista och råsvar som en artefakt. Om API-anropet misslyckas ska grinden ge utred, inte återanvända ett gammalt grönt svar utan att markera dess ålder.

Steg 3: skilj fyra beslut åt

Dokumentera beslutet per versionsgrupp, inte enbart per maskin. Ett minimalt protokoll innehåller version, antal hittade runners, båda API-datumen, ägare, vald åtgärd och ett utgångsdatum för godkännandet. Då går det att upptäcka att tio ersättningsnoder fortfarande byggs från samma gamla grundimage även om nio av dem råkade vara avstängda under inventeringen.

Versionsgrinden slutar inte vid den körande processen

GitHub rekommenderar uttryckligen att installationsskript, VM-images, container-images och deploymentautomation uppdateras samt att runners från äldre cachelagrade mallar återskapas. Gör därför en sökning efter nedladdnings-URL:er, versionsvariabler och avstängd autouppdatering. Koppla varje träff till versionsrapporten. Annars kan en lyckad manuell uppgradering döljas av att nästa autoskalade nod startar med den gamla binären.

Autouppdatering kan enligt GitHub uppfylla 30-dagarskravet om runnern når uppdateringstjänsten. Det är fortfarande värt att prova en kall nyetablering. Skapa en tillfällig runner från samma mall som produktionen, registrera den, kör ett litet workflow och avregistrera den. Det testet fångar andra fel än en inventering av redan anslutna processer.

Ge kodagenten ett mätbart uppdrag

Om en AI-agent ska bygga grinden, beställ artefakten och stoppregeln i samma prompt. Ett användbart uppdrag är: ”Hämta alla organisationsrunners med paginering, gruppera dem efter exakt version, fråga deprecation-endpointen per version och skriv TSV plus rå JSON. Markera passerat registreringsdatum, passerat runtimedatum och okänd tidpunkt var för sig. Ändra inga runners. Visa kommandon, felhantering och ett exempeltest med fixturer.”

Godkänn först när testet omfattar fler än 100 runners, två runners med samma version, en offline-runner, null eller saknat datum och ett API-fel. Det poängkriteriet mäter samma sak som prompten beställer. Lägg därefter kontrollen i er befintliga CI-grind före merge eller i ett schemalagt driftjobb. För generell övertagning av en AI-byggd lösning kan du även använda Monkeybases stabiliseringsspår för vibecoding, men håll runner-versionen som ett eget verifierbart beslut.

Slutresultatet är ett daterat underlag där varje upptäckt version har ett råsvar, två separata riskbedömningar och en ägare som antingen uppgraderar eller godkänner ett tidsbegränsat undantag. Kör om kontrollen efter imagebytet och spara både före- och efterrapporten.