Máquinas de runner

Jobs Windows, macOS e self-hosted, em máquinas que você registra.

Alguns jobs não rodam no cluster. Um container Windows precisa do kernel NT e não existe num host Linux, e o macOS não containeriza — então, para windows-latest e macos-latest, não há pod em lugar nenhum. Você registra a máquina, e a plataforma chega nela por SSH.

Quando você precisa de uma#

Um job cujas labels não batem com nenhuma máquina falha na hora em vez de rodar no lugar errado, e a anotação dele diz o que falta: nenhuma máquina para aquele OS, uma máquina em drenagem ou uma label que nenhuma tem. O run falha em vez de reportar sucesso para algo que nunca foi construído.

Registrando uma máquina#

Vá em Configurações → Plataforma → Máquinas de runner e clique em Registrar máquina. Você declara o que a máquina é: endereço, a conta com que o CI vai rodar, o sistema, a arquitetura e quantos jobs ela aceita ao mesmo tempo.

Em nenhum momento você é convidado a colar uma chave privada. A plataforma gera um par ed25519, cifra a metade privada em repouso com a mesma cifra dos secrets, e mostra apenas a pública.

Instalando a chave#

A tela entrega o comando do sistema daquela máquina, porque o destino é realmente diferente.

No Linux e no macOS, o lugar de sempre:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA… eqs-mac-mini-1' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

No Windows, não é esse lugar. Para qualquer conta do grupo Administrators, o OpenSSH lê um arquivo da máquina inteira e ignora o ~/.ssh/authorized_keys por completo:

Add-Content -Path "$env:ProgramData\ssh\administrators_authorized_keys" -Value 'ssh-ed25519 AAAA… eqs-win-runner-1'
icacls "$env:ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

Testando a conexão#

O Testar abre uma sessão e pergunta à máquina o que ela é. Uma ida e volta responde três coisas: o SSH funciona, existe um shell POSIX ali, e qual máquina é essa de verdade.

Uma máquina registrada com o sistema errado falha no teste e diz isso. Não é um problema de conexão, e é pior que um: o roteamento mandaria jobs windows-latest para uma caixa Linux, e cada um falharia num comando que não existe, sem nada apontando de volta para o registro.

Quando o teste falha você recebe o motivo literal — ssh: connect to host 10.0.0.42 port 22: Operation timed out — em vez de um erro genérico. Uma máquina que nunca foi alcançada diz isso, o que é diferente de inalcançável.

O que a máquina precisa ter#

• Um servidor SSH e uma conta sem privilégios para o CI rodar.
• Um shell POSIX. No Windows isso é o Git for Windows, com o bash.exe dele configurado como DefaultShell do OpenSSH — todo step passa por ele.
• git e tar, que o Git for Windows já traz.

Nada além disso. O runtime de Node que as actions JavaScript usam é colocado pela plataforma — construído para o sistema e a arquitetura daquela máquina — no primeiro job que rodar ali.

Drenar e remover#

Drenar termina os jobs em curso e não aceita novos: é o estado para usar antes de reiniciar ou atualizar a máquina. Remover faz a plataforma esquecê-la.

O isolamento é mais fraco que um container#

Vale dizer sem rodeios. Um job numa máquina registrada vê o que o job anterior deixou fora do workspace dele: o diretório home, o /tmp, os pacotes instalados, o estado de qualquer daemon. Um container dá uma raiz nova a cada vez, e isso aqui não dá.

O que está mitigado: a conta não tem privilégios, o workspace é por job, e a limpeza recusa qualquer caminho fora da raiz de trabalho. Use uma máquina registrada para o trabalho que você rodaria tranquilo numa build box compartilhada.