Migre dos runners hospedados pelo GitHub

O guia completo de migração: o que realmente muda, os três caminhos de migração, o mapeamento exato de rótulos que a ferramenta Migrate Runners aplica, o que os PRs contêm, verificação e rollback.

Migrar para os runners do Latchkey é uma mudança de roteamento, não uma reescrita. O rótulo runs-on: é a única coisa que decide qual runner pega um job, então é a única coisa que uma migração toca. Todo o resto continua funcionando exatamente como antes: as actions que você chama, os segredos que o GitHub injeta, seus environments e regras de proteção, e os caches do lado do GitHub. E os rótulos hospedados pelo GitHub continuam funcionando lado a lado com os rótulos latchkey-*, então nada força uma virada completa.

O que muda e o que continua funcionando#

Antes de começar#

Três formas de migrar#

Os três caminhos se compõem: a maioria das equipes edita um workflow à mão como piloto, migra em massa com a ferramenta e recorre ao AI Scan no punhado de repositórios que merecem uma imagem própria.

Caminho 1: a ferramenta Migrate Runners#

A ferramenta tem dois pontos de entrada, e ambos abrem o mesmo modal: o item Migrate Runners na barra lateral do dashboard e o CTA no rodapé do cartão Runner Types na página de Runners. Abrir PRs de migração requer um papel de owner ou admin.

Nada em um repositório muda até sua equipe fazer merge do pull request dele. Se um repositório já tiver um PR de migração aberto, a ferramenta o vincula em vez de abrir um duplicado; se não sobrar nada para trocar, ela mostra um estado Nothing to migrate. Com mais de 20 repositórios para mover, migre em passagens.

O mapeamento exato que a ferramenta aplica#

As linhas intocadas são deliberadas: jobs que a ferramenta não consegue rotear com confiança continuam rodando exatamente onde rodam hoje, então você pode migrar sua frota Linux agora e deixar workflows de SO misto intactos com segurança. Qualquer coisa que a ferramenta pule ainda pode ser movida à mão quando você estiver pronto.

O que cada pull request contém#

Cada PR reescreve as linhas runs-on: e nada mais; como o próprio corpo do PR coloca, "Only runs-on: lines were touched. Every other line in each file is byte-identical." A única exceção: quando a migração também injeta passos de cache do Latchkey, esses passos são as únicas adições além das linhas runs-on, e o corpo diz isso. 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.

Caminho 2: edite um único workflow à mão#

Para um workflow, a mudança é uma linha por job, e ambas as formas de rótulo roteiam de forma idêntica:

jobs:
  test:
    runs-on: latchkey-small

jobs:
  test:
    runs-on: [self-hosted, latchkey-small]

A versão passo a passo deste caminho, incluindo verificar a primeira execução e escolher um tamanho, é Execute seu primeiro job.

Caminho 3: AI Scan, para repos que merecem uma imagem própria#

Alguns repositórios valem mais do que uma troca de rótulo. O AI Scan lê os workflows que um repositório realmente executa e propõe uma configuração de runner personalizada com um formato sob medida e uma imagem que pré-instala a cadeia de ferramentas do repo, então os jobs pulam seus passos de setup por completo. Se isso soa como um dos seus, comece em Runners personalizados com AI Scan e migre esse repositório para o rótulo personalizado dele em vez de um preset.

Uma estratégia incremental#

Você não precisa de uma migração de uma só vez, e sugerimos evitá-la. Comece com um repositório de baixo risco, idealmente um instável ou lento, onde minutos mais baratos, captação mais rápida e autorreparo são mais visíveis, e deixe-o rodar por uma semana antes de comprometer a frota.

Jobs que precisam de GPU, Windows, macOS ou hosts arm64 permanecem nos hospedados pelo GitHub ou em outros runners, e isso é normal indefinidamente: o runs-on é decidido por job, então um workflow pode misturar jobs do Latchkey e hospedados pelo GitHub livremente.

Verifique após o merge#

Revertendo#

O rollback é a mesma mudança de uma linha ao contrário: reverta o PR de migração e os jobs voltam a ser roteados para os runners hospedados pelo GitHub imediatamente. Não há mais nada para desfazer, nenhum agente para desinstalar e nenhuma configuração para limpar, e o repositório permanece monitorado, então suas análises continuam de qualquer forma.

Perguntas comuns#