Índice do artigofaltam 2 min de leitura
faltam 2 min de leitura
Runner macOS costuma ser o mais caro (em tempo e dinheiro) e o mais sensível (ambiente) dentro de um CI/CD.
Se você precisa de Xcode, codesign, notarization ou testes específicos de macOS, não tem muito “atalho”: você precisa de macOS em algum ponto do pipeline.
Este post faz parte da série:
Mapa da série CI/CD
- Guia de CI/CD no Git para times pequenos: performance, cache e runners
- GitLab CI: tags de runner e roteamento de jobs
- Cache no CI/CD: como desenhar keys e evitar cache inválido (GitHub e GitLab)
- Docker layer caching no CI: BuildKit, buildx, cache-from e cache-to
- Runner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno
- Runners macOS no CI: Intel vs Apple Silicon, custos e armadilhas
1) Quando você realmente precisa de macOS runner
Use macOS runner apenas quando necessário, por exemplo:
- build iOS/macOS com Xcode
- codesign e notarization
- testes que dependem de frameworks do macOS
Evite:
- rodar lint, testes unitários gerais, ou docker build no macOS
- transformar macOS runner em runner “padrão”
2) GitHub Actions: macos-latest, Intel e ARM
No GitHub Actions, o runs-on define o tipo de runner.
O detalhe importante: existem variações Intel e Apple Silicon (ARM64). Isso impacta:
- tempo de build
- compatibilidade de dependências nativas
- cache (arquiteturas não compartilham bem)
Dica prática:
- mantenha cache key com
runner.arch - separe workflows por arquitetura quando necessário
3) GitLab Runner no macOS: atenção ao executor e segurança
No GitLab, um padrão comum no macOS é usar executor shell.
Isso significa que os jobs rodam diretamente no host.
Recomendação prática para times pequenos:
- trate o macOS runner como dedicado e isolado
- limite quais projetos podem usá-lo
- documente o que roda ali (Xcode, certificados, dependências)
4) Performance: onde otimizar primeiro
O que mais costuma dar ganho:
- reduzir tarefas que rodam no macOS (deixar só o essencial)
- cache de dependências (com keys bem desenhadas)
- paralelizar testes fora do macOS quando possível
O que dá ganho menor (mas ajuda):
- cache de DerivedData com estratégia (cuidado para não contaminar)
- pré-instalar ferramentas para reduzir setup
Checklist final
- macOS runner só executa jobs que realmente precisam de macOS.
- Arquitetura (Intel vs ARM) está explícita em
runs-one cache keys. - Runner macOS é tratado como dedicado/isolado.
- Existe estratégia para certificados e segredos com segurança.
- Pipeline é observável (fila vs execução e variação).
