Como funciona o provisionamento

O que acontece entre um job entrar na fila do GitHub e um runner o pegar: pools a quente, inícios a frio com registro just-in-time, o teto de concorrência e por que um job pode esperar.

Quando o GitHub enfileira um job com um rótulo latchkey-*, um webhook avisa o Latchkey imediatamente, e o Latchkey toma uma decisão: entregar o job a um runner que já está aquecido ou lançar uma máquina nova para ele. Você nunca vê essa decisão, mas ela é a diferença entre uma captação em poucos segundos e uma em cerca de dez, e ela explica a maior parte do que esta página cobre.

Captação a quente vs início a frio#

Uma captação a quente significa que um runner pré-provisionado já estava online para o seu workspace: o job é entregue direto a ele e começa em poucos segundos. Um início a frio significa que nenhum runner a quente servia, então uma máquina nova inicializa só para aquele job, registra-se no GitHub usando uma configuração just-in-time de uso único e está executando seus passos em cerca de 10 segundos. Os dois caminhos terminam de forma idêntica: o runner pega exatamente um job e a máquina é encerrada quando o job termina.

Pools a quente#

Hoje todo plano recebe a mesma linha de base a quente, e ela cobre apenas latchkey-small: um runner a quente sempre ligado, apoiado por máquinas estacionadas que retomam em segundos. Qualquer coisa além disso, e qualquer job que peça um tamanho maior, faz início a frio em cerca de 10 segundos. A capacidade a quente não custa nada enquanto está ociosa; a cobrança é por minuto de job, e um runner a quente ocioso não está executando um job.

Efêmero, sempre#

O provisionamento nunca reutiliza uma máquina. A quente ou a frio, um runner pega exatamente um job e é encerrado em seguida, junto com seu disco, e é por isso que os nomes de runner na visualização de execução do GitHub mudam a cada execução e por isso que qualquer coisa que um job escreva no disco local some quando o job termina. O lado de segurança desse design, credenciais just-in-time, rede privada e discos criptografados de uso único, é coberto em Arquitetura de segurança.

Concorrência#

Um workspace executa até 20 runners ocupados simultaneamente por padrão, e só runners ocupados contam: runners a quente ociosos nunca consomem uma vaga, então a capacidade a quente não compete com seus jobs reais. Quando um pico precisa de mais de 20 de uma vez, os jobs excedentes ficam na fila até uma vaga liberar e então começam sozinhos; nada dá erro e nada se perde. Se seus picos entram na fila com frequência, limites maiores estão disponíveis, contate o suporte.

Limites rígidos#

• Jobs têm teto de 4 horas; a máquina é encerrada às 4 horas mesmo que o job ainda esteja rodando.
• Os runners são apenas Ubuntu 24.04 LTS em x86_64: sem hosts Windows, macOS, arm64 ou GPU.
• Os runners rodam em AWS us-east-1.

A tabela completa, incluindo tamanhos de disco e contagens de configurações personalizadas por plano, está em Limites e concorrência.

Por que um job pode ficar parado na fila#

Quando o provisionamento não pode ou não vai lançar um runner, não há erro do lado do GitHub; o job simplesmente espera. Isso é por design: jobs direcionados a rótulos latchkey-* permanecem na fila do GitHub em vez de dar erro. As causas usuais:

• Um erro de digitação no rótulo: nenhuma configuração corresponde ao rótulo, então nada nunca pega o job.
• O repositório não está monitorado, ou a configuração do runner está desabilitada.
• Um bloqueio de cobrança ou trial: um trial expirado, uma assinatura vencida ou um nível gratuito esgotado em um trial sem cartão. Uma notificação "Managed runner blocked" dispara quando isso acontece, no máximo uma vez por dia.
• A imagem de um runner personalizado ainda está sendo construída; jobs direcionados ao rótulo dele esperam até o build terminar.
• O workspace está no seu teto de 20 runners ocupados; o job começa assim que uma vaga libera.

O passo a passo sintoma por sintoma, com como confirmar cada causa, está em Solução de problemas.