Menu da documentação
Painel e análises
Runners gerenciados
Equipe e notificações
Faturamento e planos
Arquivos de workflow
A página de Runners: gerenciamento da frota
Gerencie sua frota de runners a partir do dashboard: tipos de runner, configurações, uso e economia, o feed de atividade de autorreparo e a ferramenta de migração em massa.
Resumo
- A página Runners = custo e economia da frota, configurações de runner e o feed de atividade de autorreparo.
- Habilitação/desabilitação e concorrência máxima por configuração, e status de build de imagem para runners personalizados; o autorreparo é controlado em todo o workspace nas Configurações.
- Migrate Runners (item da barra lateral ou cartão Runner Types, owners/admins) abre um PR por repositório, até 20 repos monitorados por passagem; apenas as linhas
runs-onmudam, além dos passos de cache do Latchkey quando adicionados.
Tudo sobre sua frota de runners gerenciados fica na página Runners ("Manage your runners and review jobs they've run") na barra lateral do dashboard. É o lar operacional dos recursos descritos no restante desta seção.
O que há na página#
Uma revisão semanal de cinco minutos#
A página recompensa um breve hábito semanal. Uma passagem sugerida:
Revisão semanal da frota
A tabela Your runners#
A tabela Your runners ("Set up runners for your repos. Adjust size, concurrency, and on/off state.") lista toda configuração no seu workspace: os quatro presets mais quaisquer runners personalizados. As colunas cobrem nome, status, tamanho, concorrência máxima, estado de autorreparo e estado ativo, e o cabeçalho da tabela carrega a ação AI Scan Runners; antes do seu primeiro runner ela mostra um estado vazio Set up your first runner, e banners de scans pendentes ("Ready for review") aparecem acima dela. Cada linha lhe dá:
- Habilitar/desabilitar. Uma configuração desabilitada para de aceitar novos jobs (jobs que apontam para seu rótulo ficarão na fila).
- Copy CI snippet, para que ninguém digite um rótulo de memória.
- Uma coluna Self Healing mostrando se o reparo cobre o runner; o controle em si é o interruptor de todo o workspace em Settings, Self-healing.
- Status de build de imagem para runners personalizados: você pode ver quando uma imagem personalizada ainda está sendo construída versus pronta.
- Excluir para configurações personalizadas que você não precisa mais.
Desabilitar e excluir fazem coisas diferentes. Desabilitar é o botão de pausa: o rótulo continua existindo, e jobs que o apontam ficam na fila até você reabilitá-lo, o que o torna a jogada certa enquanto você investiga uma configuração. Excluir é para configurações personalizadas com as quais você terminou de forma permanente.
O painel de detalhes#
Clicar em uma linha abre o painel de detalhes com a configuração completa: rótulo, SO, vCPUs, RAM, disco, imagem base e preço por minuto, além de um cartão Use in CI com o rótulo e um snippet copiável do GitHub Actions. Admins podem editar o nome do runner, os rótulos personalizados e Max Concurrent (0 = ilimitado); não-admins veem os mesmos detalhes somente para leitura, para que toda a equipe possa ver o que cada runner oferece.
Recent Heals#
A seção de autorreparo ("Recent heal attempts, agent reports, and PR proposals across your org.") lista cada reparo com seu selo de resultado (Healed, No Action, Failed ou Pending) e categoria, abaixo dos KPIs de reparos e dos gráficos Heal Activity Over Time e Heal Rate by Category. Clicar em uma linha abre o painel Heal Details com o relatório completo: o que falhou, o diagnóstico, a ação exata tomada (em linguagem simples) e, para falhas diagnosticadas por IA, as iterações do agente. Execuções reparadas em Desempenho de pipeline têm links diretos para os mesmos relatórios. Se o autorreparo estiver desligado, a seção mostra "Self-Healing is disabled." com um link para habilitá-lo nas Configurações.
Leia o feed como um sinal, não apenas um registro de resgates. Reparos de rede pontuais e dispersos por muitos workflows são o ruído de fundo normal de registries e serviços externos tendo maus momentos. Os padrões são mais interessantes: o mesmo workflow reparado repetidamente na mesma categoria aponta para algo duradouro. Reparos de memória recorrentes sugerem um job que quer um tamanho de runner maior; reparos de disco recorrentes, um job que enche seu disco a cada execução; reparos de ferramenta recorrentes, um passo que assume uma ferramenta que o workflow nunca instala. Esses são exatamente os casos em que uma correção permanente supera ser resgatado toda noite; veja pull requests de reparo para saber como o autorreparo propõe essas correções por conta própria.
Migrate Runners#
A ferramenta tem dois pontos de entrada, e ambos abrem o mesmo modal Migrate runners: o item Migrate Runners na barra lateral do dashboard e o CTA no rodapé do cartão Runner Types ("Already have workflows on GitHub-hosted runners? Migrate them to Latchkey runners in a few clicks."). Esta seção cobre o modal em si; o guia completo, incluindo o mapeamento exato de rótulos, o conteúdo dos PRs, a verificação e o rollback, é Migre dos runners hospedados pelo GitHub.
- 01Abra a ferramentaA partir do item da barra lateral ou do rodapé do cartão Runner Types (owners e admins)
- 02Escolha repositóriosAté 20 repos monitorados, com um contador de N/20 selecionados
- 03Abra PRs de migraçãoO Latchkey abre um pull request por repositório
- 04Revise e faça mergeNada muda até sua equipe fazer merge de cada PR
Cada pull request reescreve todo rótulo runs-on suportado para o tamanho certo do Latchkey (rótulos Ubuntu padrão viram latchkey-small) e não toca em mais nada; jobs Windows e macOS, rótulos não reconhecidos e linhas com expressões ${{ }} são deixados em paz. Uma tabela de mapeamento antes e depois para cada arquivo mostra exatamente o que mudou, então a revisão leva minutos, não dias.
- Depois que os PRs estão abertos, o modal lista cada um com seu número de PR e um link View PR: "Opened N pull requests. Merge each on your schedule."
- Se um repositório já tiver um pull request de migração aberto, o Latchkey o vincula em vez de abrir um duplicado.
- Se não sobrar nada para trocar, o modal mostra um estado Nothing to migrate.
- Abrir PRs de migração requer um papel de admin ou owner; nada nos seus repositórios muda até sua equipe fazer merge.
O que há na página Runners?
Custo e economia da frota, suas configurações de runner e o feed de atividade do autorreparo em um só lugar. Cada configuração pode ser ativada ou desativada, receber uma concorrência máxima e mostra o status de build de imagem para runners personalizados.
Como migro repositórios para runners Latchkey em lote?
Use o Migrate Runners, na barra lateral ou no card Runner Types, disponível para owners e admins. Ele abre um pull request por repositório em até 20 repositórios monitorados por passagem, alterando apenas as linhas runs-on e os passos de cache do Latchkey quando adicionados.
Onde ativo ou desativo o autorreparo?
Em Settings, para todo o workspace, e não por configuração. A página Runners controla ativação e concorrência por configuração; o autorreparo é um único interruptor de workspace, para que seu comportamento não divirja entre tipos de runner.