A página de Runners: gerenciamento da frota

Gerencie sua frota de runners a partir do dashboard: configurações, alternadores de autorreparo por runner, uso e economia, o feed Recent Heals e a ferramenta de migração em massa.

A página de Runners do Latchkey — 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 Latchkey Runners 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 TypesOs tamanhos predefinidos com especificações e preços por minuto, sempre à mão na hora de escolher um rótulo.

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

Atividade de autorreparoKPIs de reparos, tendências, detalhamento por 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 lista toda configuração no seu workspace: os quatro presets mais quaisquer runners personalizados. Cada linha mostra o tamanho, o status de build de imagem, a concorrência máxima e o estado ligado/desligado, além de uma ação Copy CI snippet por linha para que ninguém digite um rótulo de memória. 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).
Alternador de autorreparo por configuração, além do modo em nível de workspace nas Configurações, para que você possa excluir um tipo de runner específico do reparo.
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 alternador de reparo por configuração é a ferramenta de precisão: ele permite manter o autorreparo ligado em todos os lugares, exceto em um tipo de runner, sem tocar no modo em nível de workspace nas Configurações.

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 lista cada reparo com seu veredito e categoria. Abrir uma linha mostra 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, esta seção o conecta ao alternador 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#

01Abra a ferramentaA partir do cartão Runner Types (owners e admins)

02Escolha repositóriosAté 20 repos monitorados de uma lista pesquisável

03Abra PR(s) 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 um runner do Latchkey: rótulos Ubuntu padrão mudam para latchkey-small, o tamanho de menor custo, e outros rótulos suportados mudam para o menor tamanho do Latchkey que atenda à sua CPU e memória. Apenas as linhas runs-on mudam; como cada corpo de PR coloca, "Only runs-on: lines were touched. Every other line in each file is byte-identical." 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.

A ferramenta deliberadamente deixa algumas coisas em paz: jobs Windows e macOS, rótulos self-hosted que ela não reconhece, e expressões de matrix como ${{ matrix.os }} (incluindo definições de eixo de matrix). Esses jobs continuam rodando exatamente onde rodam hoje, então você pode migrar seus jobs Linux agora e deixar workflows de SO misto intactos com segurança.

Um ritmo sugerido para a ferramenta: migre em ondas em vez de tudo de uma vez. Mova seu primeiro workflow à mão (uma linha de YAML), deixe-o rodar por uma semana e depois traga a maior parte da frota quando confiar nos números que vê aqui.