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.

A página de Runners: métricas da frota e configurações de runner — A página de Runners: métricas da frota e suas configurações de runner.

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#

Métricas da frotaCusto de runners neste período de cobrança, economia estimada vs hospedados pelo GitHub, e minutos do nível gratuito usados contra sua franquia mensal.

Runner TypesUm cartão recolhível cobrindo Preset Runners (os quatro tamanhos com especificações e preços por minuto) e AI Scan Runners, com um atalho Migrate Runners no seu rodapé.

Your runnersToda configuração no seu workspace: nome, status, tamanho, concorrência máxima, estado de autorreparo e ligado/desligado, além de uma ação Copy CI snippet por linha.

Atividade de autorreparoKPIs de reparos (Total Attempts, Heals, Success Rate), gráficos de atividade e de categoria, e o feed Recent Heals.

Uma revisão semanal de cinco minutos#

A página recompensa um breve hábito semanal. Uma passagem sugerida:

Revisão semanal da frota

Métricas da frota: o custo dos runners está seguindo o esperado para este período de cobrança, e quanto da franquia do nível gratuito ainda resta?Economia estimada vs hospedados pelo GitHub: ainda é o que você espera? É sua evidência contínua de que a migração continua compensando.Your runners: há algo desabilitado que workflows ainda apontam? Jobs direcionados a um rótulo desabilitado ficam na fila em vez de falhar, o que é fácil de não notar.Runners personalizados: há builds de imagem ainda pendentes ou que falharam? A linha da configuração mostra o status do build.Recent Heals: quais categorias dominam esta semana, e algum workflow específico está sendo reparado repetidamente?

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.

References

GitHub Actions documentation