Resposta rápida
O GitHub vai retirar em 2 de novembro de 2026 os labels macos-14, macos-14-large e macos-14-xlarge dos runners hospedados do GitHub Actions. Antes da remoção, jobs que ainda usam esses labels falharão temporariamente em oito brownouts programados para outubro. Procure as referências em .github/workflows e em workflows reutilizáveis, escolha uma imagem macOS 15 ou macOS 26 compatível com a arquitetura exigida e teste antes do primeiro brownout.
Não substitua o label às cegas. macos-14 e macos-14-xlarge são imagens arm64, enquanto macos-14-large é Intel x64. Preserve a arquitetura quando o build depende de binários, simuladores, plugins ou ferramentas sem suporte a arm64; depois confira a versão de Xcode e o software realmente instalado no runner usado pelo job.
Quando os jobs vão falhar
O GitHub programou períodos de brownout para 5, 12, 16, 19, 23, 26, 29 e 30 de outubro. Cada janela vai de 14h UTC até 0h UTC do dia seguinte, o que corresponde a 11h às 21h no horário de Brasília (UTC-3) na data inicial. Durante essas dez horas, um job ainda preso ao macOS 14 pode falhar de propósito para tornar a dependência visível.
Até a aposentadoria, a capacidade do macOS 14 também pode ser reduzida. Portanto, uma fila mais lenta não prova sozinha que o Actions caiu. Confirme o label do job, compare o horário com o brownout e consulte o GitHub Status antes de aumentar timeouts ou reexecutar o pipeline repetidamente.
- 5 de outubro, das 11h às 21h de Brasília.
- 12, 16, 19, 23, 26, 29 e 30 de outubro, sempre das 11h às 21h de Brasília.
- 2 de novembro: retirada definitiva anunciada para os três labels macOS 14.
Como encontrar todos os usos de macOS 14
Pesquise o repositório inteiro, não apenas o workflow que falhou. O label pode estar diretamente em runs-on, dentro de strategy.matrix, em um workflow reutilizável chamado por vários projetos ou em uma action composta que encaminha parâmetros. Organizações que mantêm templates centrais devem corrigir a fonte e também localizar cópias antigas já distribuídas.
Uma busca local com rg -n 'macos-14(-large|-xlarge)?' .github encontra as ocorrências diretas nos arquivos versionados. No GitHub, a pesquisa de código da organização ajuda a inventariar vários repositórios. Revise o resultado manualmente: documentação e exemplos não executam jobs, enquanto YAML gerado ou um repositório de templates pode afetar muitos pipelines.
- Liste arquivos em .github/workflows que definem runs-on ou matrix.os.
- Abra workflows reutilizáveis referenciados por uses: organização/repositório/.github/workflows/arquivo@ref.
- Procure templates, scripts e geradores que ainda escrevem macos-14.
- Registre responsável, label atual, arquitetura, versão de Xcode e criticidade de cada job.
Qual label usar no lugar
Para jobs arm64, o anúncio recomenda macos-15 ou macos-latest, que atualmente aponta para macOS 26. Em runners maiores arm64, use macos-15-xlarge ou macos-latest-xlarge, atualmente associado ao macOS 26 xlarge. Fixar macos-15 reduz a mudança imediata; escolher latest aceita migrações futuras anunciadas pelo GitHub e exige testes contínuos.
Para um job em macos-14-large, preserve Intel com macos-15-large ou outro label Intel disponível no repositório oficial de runner images. Trocar large por macos-15 ou latest muda de x64 para arm64. Essa alteração pode exigir dependências universais, atualização de caches, nova configuração do build e revisão de custos dos larger runners.
- macos-14: teste macos-15; use macos-latest somente se o projeto aceita acompanhar a imagem estável mais nova.
- macos-14-xlarge: teste macos-15-xlarge ou macos-latest-xlarge.
- macos-14-large: teste macos-15-large para conservar a arquitetura Intel x64.
- Consulte actions/runner-images no dia da migração, porque aliases e software instalado mudam ao longo do tempo.
Faça uma migração mínima e reversível
Crie uma branch dedicada e altere primeiro um job representativo. Se usa matriz, adicione temporariamente o novo label ao lado do antigo para comparar resultados, duração e artefatos. Não deixe a duplicação permanente sem revisar consumo, pois cada combinação da matriz cria outro job e pode aumentar a cobrança.
Fixe explicitamente as versões de ferramentas que o build precisa. A documentação do GitHub recomenda actions de setup porque elas tornam a versão menos dependente das atualizações semanais da imagem. No log do job, expanda Set up job e Runner Image para abrir a relação exata de software incluído naquela execução.
- Troque apenas o label do runner em uma branch de teste.
- Execute build, testes, assinatura, empacotamento e publicação sem usar credenciais de produção quando possível.
- Compare arquitetura com uname -m, versão do sistema com sw_vers e Xcode com xcodebuild -version.
- Valide o conteúdo e a assinatura dos artefatos, não apenas o status verde do job.
- Promova o novo label e remova a combinação antiga antes da retirada definitiva.
O que costuma quebrar ao mudar a imagem
A falha mais comum é um binário x86_64 sem versão arm64. Também verifique gems nativas, Homebrew, CocoaPods, simuladores, plugins de Xcode, caches compilados para outra arquitetura e scripts que assumem caminhos específicos. Uma chave de cache que não inclui sistema, arquitetura e versão relevante pode restaurar artefatos incompatíveis no novo runner.
Outra diferença é a versão de Xcode. Mesmo dentro do mesmo macOS, a imagem é atualizada semanalmente e pode mudar SDKs e ferramentas. Se o aplicativo precisa de uma versão específica, selecione-a de forma explícita e valide a lista de software incluído. Não copie um caminho de Xcode de outra imagem sem conferir se ele existe na release atual.
Como diagnosticar uma falha no brownout
Abra o job e verifique o valor resolvido de runs-on. Em matrizes, o YAML pode mostrar uma variável enquanto o resumo do job revela o label efetivo. Se o job nem começa, compare a janela com o cronograma, confirme que o label foi alterado na ref executada e confira se o workflow reutilizável está fixado em uma tag ou SHA antigo.
Se o job começa e falha em uma etapa, o problema já não é falta do runner: investigue arquitetura, Xcode, dependências e cache. Use os logs do workflow e ative debug somente quando necessário. Não imprima secrets ou credenciais para provar que uma variável existe; o log pode virar uma nova exposição de segurança.
Limitações e próxima ação útil
Este guia foi verificado em 2 de outubro de 2026. O cronograma se refere aos runners hospedados do GitHub Actions em github.com; runners próprios e GitHub Enterprise Server seguem a imagem e o ciclo administrados pela organização. O GitHub Status mostra disponibilidade geral, mas não confirma que um binário, SDK ou action de terceiros seja compatível com a nova arquitetura.
Faça hoje o inventário com uma busca por macos-14, migre um job de baixo risco para o label escolhido e valide o artefato completo. O primeiro brownout começa em 5 de outubro, então esperar uma falha real deixa pouco tempo para corrigir dependências, assinatura e caches antes das próximas janelas.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- GitHub Actions: macOS 14 runner image retirementGitHub Changelog
- GitHub-hosted runnersGitHub Docs
- GitHub Actions Runner ImagesGitHub
- Larger runners referenceGitHub Docs
- Choosing the runner for a jobGitHub Docs
- Viewing workflow run historyGitHub Docs
- GitHub StatusGitHub