Migrar dos GitHub Larger Runners para o Latchkey
Os GitHub larger runners dão nativamente mais cores a jobs pesados. Se a dor é a conta por minuto, mover esses jobs para o Latchkey é, na maior parte, uma mudança de runs-on.
Os GitHub larger runners são VMs gerenciadas de primeira parte com mais cores, RAM e disco que os runners padrão. Segundo a documentação do GitHub, eles são cobrados a uma taxa por minuto e os minutos incluídos não podem ser usados neles. O Latchkey roda os mesmos jobs em runners gerenciados acessados por uma mudança de runs-on, tipicamente a uma taxa menor por minuto, e adiciona autocorreção para que falhas transitórias sejam reexecutadas automaticamente. Aqui está como é uma migração e onde cada opção é mais forte. Verifique o preço atual do GitHub no site deles, já que preços de fornecedores mudam.
O que muda quando você migra
| GitHub larger runners | Latchkey | |
|---|---|---|
| Modelo de runner | VMs gerenciadas de primeira parte | Runners gerenciados de terceiros |
| Como você direciona | Grupo de runner + label customizado | Troca de label runs-on |
| Minutos incluídos/gratuitos se aplicam | Não (segundo a doc do GitHub) | Camada gratuita incluída |
| Autocorreção de falhas transitórias | Não | Sim (detecta/corrige/reexecuta automaticamente) |
| Gestão de grupo de runner / label | Você gerencia | Não é necessária |
| Integração nativa com o GitHub | Mais profunda (embutida) | Integração padrão de runner |
O que continua igual
Seu YAML de workflow, actions, secrets e o grafo de jobs ficam inalterados. Você continua rodando GitHub Actions; só está mudando em qual runner os jobs pesados caem.
O que muda
- Direcionamento: em vez de um nome de grupo de runner mais um label customizado de larger runner, você aponta o runs-on para um label do Latchkey.
- Faturamento: os larger runners cobram por minuto sem franquia de minutos incluídos (segundo a doc do GitHub). O Latchkey aplica seu próprio preço com uma camada gratuita incluída.
- Confiabilidade: falhas transitórias e mecânicas (kills por OOM, disco cheio, timeouts de registry) se autocorrigem e são reexecutadas no Latchkey em vez de derrubar a execução.
Onde os GitHub larger runners continuam sendo a melhor opção
Se você quer zero envolvimento de terceiros, a integração mais profunda com o GitHub ou recursos ligados ao GitHub Enterprise Cloud como faixas de IP estático para larger runners, ficar nos larger runners de primeira parte é uma escolha legítima. O trade-off é uma taxa por minuto mais alta e nenhuma autocorreção.
Um caminho de migração seguro
- Escolha um workflow pesado atualmente em um larger runner.
- Duplique-o e troque o runs-on para um label do Latchkey na cópia.
- Rode os dois por uma semana e compare tempo de relógio, custo por minuto e contagem de re-execuções.
- Espalhe o resto quando os números se sustentarem para seus builds reais.
O veredito
Se seus jobs pesados rodam com frequência e a conta por minuto dos larger runners é a dor, migrar esses jobs para o Latchkey geralmente reduz o custo e remove re-execuções instáveis mantendo seus workflows intactos. Se a integração nativa e o faturamento de primeira parte importam mais que o preço por minuto, os GitHub larger runners são um lugar razoável para ficar. Comece de graça e compare com seus builds reais.