Baixando a conta de macOS no GitHub Actions, passo a passo
A maioria das contas de macOS no GitHub Actions é inflada por minutos que não fazem nada pela equipe. Refazer caches. Rodar matrizes que ninguém lê. Terminar jobs de commits que já foram substituídos. Este é um checklist de mudanças ordenadas por quanto economizam em troca de pouco trabalho, com o YAML onde ajuda.
1. Cancele execuções que já estão velhas
Quando alguém faz dois pushes em um minuto, a primeira execução é desperdiçada. Um bloco por workflow resolve isso:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true2. Tire do macOS tudo o que não é build
Lint, checagens de formatação, notas de versão e avisos no Slack rodam num runner Linux por um décimo do preço. Testes unitários de pacotes Swift compartilhados que não tocam no UIKit também. Divida o workflow num job de Linux e num job de macOS que depende dele. Assim uma falha de lint nunca gasta um minuto de macOS.
3. Faça cache dos caminhos que custam tempo de verdade
Nos runners hospedados, cada job começa vazio. Restaure as pastas caras com uma chave ligada aos seus lockfiles:
- uses: actions/cache@v4
with:
path: |
~/Library/Developer/Xcode/DerivedData
~/Library/Caches/org.swift.swiftpm
~/.cocoapods
Pods
key: ${{ runner.os }}-${{ hashFiles('**/Package.resolved', '**/Podfile.lock') }}O DerivedData é o maior e o mais frágil. Se os builds incrementais se comportarem de um jeito estranho, tire ele do cache e fique com os caches de pacotes.
4. Rode a matriz completa só na main
Um pull request raramente precisa de cinco simuladores. Compile uma configuração nos pull requests e a matriz completa de dispositivos nos merges para a main ou numa execução noturna.
5. Filtre por caminho
Uma mudança no README não deveria disparar um build de iOS. Use paths-ignore no gatilho do workflow para docs, scripts e tudo o que estiver fora do target do app.
6. Defina timeouts
Um simulador travado pode cobrar as seis horas do limite padrão. Defina timeout-minutes em cada job de macOS, um pouco acima do seu tempo normal de build.
7. Pare de reinstalar ferramentas
Instalar CocoaPods, fastlane ou um Xcode específico em cada job queima minutos antes de o build começar. Fique com o que a imagem hospedada já tem, ou faça cache da instalação.
8. Reduza a retenção de artifacts
Arquivos e pacotes de teste guardados por 90 dias geram cobranças de armazenamento que vão subindo. Sete dias bastam para tudo o que não vai para a loja.
9. Acima do ponto de equilíbrio, pare de pagar por minuto
Tudo acima corta um pouco da conta. Quando você passa com frequência de cerca de 2,242 minutos de macOS por mês, nenhum corte vence um preço fixo. Um M6 dedicado a $139 por mês roda minutos ilimitados com caches aquecidos. Os itens 3 e 7 deixam de importar. A calculadora mostra onde a sua equipe está.
Perguntas frequentes
Qual é a maior economia numa conta de macOS do GitHub Actions?
+
Para a maioria das equipes, cancelar execuções substituídas com um grupo de concurrency e passar o trabalho que não é build para o Linux. Juntas, essas duas mudanças pequenas no YAML costumam tirar um terço dos minutos de macOS cobrados.
Vale a pena fazer cache do DerivedData no GitHub Actions?
+
Muitas vezes, mas ele é o frágil. Caches de pacotes (SwiftPM, CocoaPods) são seguros e economizam minutos em todo job. O DerivedData economiza mais, mas pode causar falhas estranhas em builds incrementais. Use uma chave bem justa e esteja pronto para tirar ele.
Devo rodar a minha matriz de dispositivos em cada pull request?
+
Normalmente não. Uma configuração nos pull requests e a matriz completa na main ou à noite pegam as mesmas regressões com uma fração dos minutos.
Quando nada disso importa?
+
Acima de cerca de 2,242 minutos de macOS por mês, um Mac dedicado de preço fixo a $139 sai mais barato que pagar por uso. Isso vale por mais otimizada que esteja a configuração por uso. Os caches aquecidos já eliminam sozinhos a maior parte do desperdício.