GitHub Actions macOS 14: stopp den 2 november – flytta bygget före nästa avbrottsfönster

Den 1 oktober kom beskedet; den 2 november upphör imagen

GitHub meddelade den 1 oktober 2026 att macOS 14-imagen för GitHub-hosted Actions-runners avvecklas den 2 november 2026. GitHubs avvecklingsnotis omfattar tre etiketter: macos-14, macos-14-large och macos-14-xlarge. Det är miljön som jobben beställer som försvinner.

Nästa planerade brownout efter artikelns kontrolldatum är 16 oktober 2026 klockan 14:00 UTC till 17 oktober klockan 00:00 UTC. Under avbrottsfönstret ska jobb som använder macOS 14 tillfälligt misslyckas enligt notisen. GitHub varnar även för möjlig kapacitetsminskning och längre köer före avvecklingen. Ett misslyckat jobb under fönstret behöver därför undersökas mot runneretiketten innan du börjar ändra applikationskoden.

Planera migrationen före nästa fönster, inte enbart före slutdatumet. Beskedets publiceringsdatum och tjänstehändelsen är två olika datum. Kontrollera originalnotisen igen när du godkänner ändringen: den här artikeln återger läget kontrollerat den 13 oktober 2026 och visar nästa fönster, inte hela brownoutkalendern.

Hitta etiketten även när den kommer från en matris

Börja i .github/workflows och sök efter alla tre etiketter. Läs sedan varje träff tillsammans med jobbnamn och utlösare. GitHubs workflowreferens beskriver hur runs-on kan använda uttryck och hur matriser och återanvändbara workflows anges. En ensam sökning efter en exakt rad med runs-on: macos-14 ger därför ett för smalt underlag.

Gå vidare från runs-on till den variabel eller indata som faktiskt väljer miljön. Kontrollera matrisvärden, särskilda include-poster och standardvärden i återanvändbara workflows. Följ även anrop till en gemensam workflowfil i ett annat repository. Spara både anroparen och definitionen i inventeringen så att det framgår var ändringen ska göras.

Ett dokumentationsbaserat sökexempel, inte kört mot något läsarrepository:

rg -n 'macos-14(-large|-xlarge)?' .github
rg -n 'runs-on:|matrix:|workflow_call:|uses:' .github/workflows

Den andra sökningen hjälper dig att följa indirekta val; den är ingen fullständig YAML-analys. Om etiketten byggs av flera strängar behöver du läsa uttrycket. Redovisa även workflows som du inte kunde inspektera. En rapport med noll bokstavliga träffar är ett sökresultat, inte ett kompatibilitetsbevis.

Gör en rad per jobb med repository, workflowfil, utlösare, nuvarande etikett, vald ersättare och ansvarig. Ta med schemalagda jobb och releaseflöden även om de inte körs på varje pull request. Markera vilka jobb som skapar leveransbara paket och vilka som bara kör tester; godkännandet behöver olika bevis för dessa två fall.

Välj arkitektur före ersättningsetikett

I runner-images-tabellen, kontrollerad den 13 oktober 2026, är macos-14-large x64. macos-14 och macos-14-xlarge är arm64. Avvecklingsnotisens korta ersättningslista visar arm64-alternativ; använd tabellen för ett x64-bygge.

Tabellen ovan är ett urval för migrationen, inte en fullständig lista över tillgängliga runners. Kontrollera att den valda storleken kan användas av din organisation. Behåll arkitekturen i den första ändringen om du saknar ett separat skäl att byta. Om du avsiktligt går från x64 till arm64 ska beslutet stå i pull requesten tillsammans med vad som ska granskas i utdata.

macos-latest pekar enligt dagens tabell på macOS 26 arm64 och är ett rörligt val. En versionsetikett väljer OS-generation, inte oförändrade versioner av varje installerat verktyg; runner-images beskriver veckovisa imageuppdateringar. Spara därför den faktiska imageversionen från körningens Set up job-logg när du granskar resultatet.

Prova samma bygge på en avgränsad gren

Skapa en testgren där du ändrar runnervalet och behåller övriga steg. Lägg inte samtidigt till en ny kompilator, en annan paketeringsmetod eller ändrade tester. Då blir det lättare att koppla ett nytt fel till miljöbytet. Välj ett representativt jobb från inventeringen och kör därefter övriga berörda jobb innan du godkänner hela migrationen.

Följande före- och efterexempel är dokumentationsbaserade och har inte körts i GitHub Actions. De visar ett avsiktligt bevarat x64-val för samma jobb; projektets faktiska byggsteg behöver ligga kvar i workflowfilen.

# Före
jobs:
  build:
    runs-on: macos-14-large

# Efter
jobs:
  build:
    runs-on: macos-15-large

Anteckna vilka verktyg jobbet förväntar sig och jämför dem med mål-imagens programvarulista i runner-images. Kontrollera särskilt vald Xcode-installation, SDK, språkversion och eventuella hårdkodade sökvägar. Om ett verktyg måste installeras av workflowet ska installationen ingå i provet. Att själva runnern startar räcker inte för att visa att projektets verktygskedja fungerar.

Kör både med tom projektcache och med den cache som workflowet normalt återställer. Jämför vilka nycklar som väljs och om de skiljer OS och arkitektur på det sätt projektet behöver. Om bara det varma bygget fungerar är migrationen ännu inte verifierad för en ny körning utan gamla byggprodukter. Spara loggarna och ange vilken variant varje resultat gäller.

Granska artefakten och signeringen före merge

Ladda ned den byggartefakt som testgrenen producerar. Kontrollera filnamn, paketets innehåll och avsedd målarkitektur. Starta eller installera resultatet i projektets överenskomna testmiljö; en grön teststatus säger inte ensam att rätt paket skapades. Jämför även mot det senaste kända godkända paketet och förklara förväntade skillnader.

Om releaseflödet signerar eller notariserar ett paket, prova den kedjan med ett avgränsat test enligt projektets releaseprocess. Kontrollera åtkomst till certifikat, keychain, profiler och de verktyg som används. Markera ett utelämnat signeringsprov som öppet i pull requesten. Flytta inte bedömningen till produktion genom att beskriva ett osignerat testpaket som verifierad release.

Godkänn när varje inventerad rad har ett motiverat runnerval, en lyckad relevant körning och granskad utdata. Använd CI-grindarna före merge för projektets befintliga stoppregler. Om köhantering behöver justeras finns guiden om GitHub Actions concurrency; håll runnerbytet som ett separat beslut med egna loggar.

Be en kodagent leverera inventeringen och en begränsad diff, inte bara ersätta text överallt. Beställ uttryckligen samma arkitektur eller ett redovisat byte och kräv att varje vald etikett kontrolleras mot den aktuella tabellen. Granska förslaget mot inventeringen och testresultaten innan merge. Gör en avslutande sökning efter gamla etiketter och bedöm kvarvarande träffar, även i mallar som kan skapa nya workflows senare.