O que há na imagem do runner

A cadeia de ferramentas pré-instalada em todo runner do Latchkey: linguagens, Docker, navegadores, bancos de dados, gerenciadores de pacotes e o toolcache compatível com o GitHub.

Todo runner inicializa a partir de uma imagem Ubuntu 24.04 LTS (x86_64) mantida, com uma cadeia de ferramentas projetada para igualar ou superar os runners hospedados pelo GitHub, então a maioria dos workflows roda sem alterações.

A cadeia de ferramentas#

Categoria	Pré-instalado
Node.js	20 (padrão), 22, 24, com npm e yarn; nvm disponível
Python	3.10 até 3.14, mais pipx e PyPy
Go	1.22 até 1.25
Java (Temurin)	8, 11, 17, 21, 25, com Maven, Gradle e Ant
Outras linguagens	Rust (stable + rustfmt + clippy), .NET 8/9/10, Ruby (+ fastlane), PHP 8.3 (+ Composer, Xdebug), Haskell, Swift, Kotlin, Julia, PowerShell
Containers	Docker CE com BuildKit, `docker buildx`, `docker compose`; Buildah, Podman, Skopeo
Navegadores	Chrome, Firefox, Edge com drivers correspondentes; Selenium; Android SDK/NDK
Bancos de dados	PostgreSQL 16, MySQL 8.0 (serviços desabilitados no boot; inicie-os no seu job)
Gerenciadores de pacotes	Homebrew, conda, vcpkg, mais os nativos de cada linguagem
Padrões de CLI	AWS CLI v2, jq, git, build essentials

Igualando o comportamento dos hospedados pelo GitHub#

A propriedade mais útil da imagem é o que você não precisa mudar. Mantenha seus passos actions/setup-node, actions/setup-python e similares exatamente como estão: eles resolvem a partir do toolcache com paridade ao GitHub em /opt/hostedtoolcache instantaneamente, em vez de baixar, então o mesmo arquivo de workflow permanece correto em ambos os tipos de runner enquanto você migra.

O conselho sobre fixação de versão é o mesmo de sempre: deixe as actions de setup declararem a versão em vez de se apoiar nos padrões da imagem. Node 20 é o padrão, com 22 e 24 também instalados, mas um passo setup-node com um node-version explícito faz o workflow dizer o que ele quer dizer, e o mantém estável à medida que a imagem mantida evolui.

Três coisas que vale a pena saber#

Docker nativoO Docker roda no próprio host: sem gambiarras de docker-in-docker, e o BuildKit está ligado por padrão.

Builds multiarquiteturaQEMU/binfmt vem pré-configurado, então docker buildx --platform linux/amd64,linux/arm64 funciona de imediato.

Toolcache com paridade ao GitHubactions/setup-node, setup-python e afins resolvem a partir de /opt/hostedtoolcache instantaneamente, sem baixar.

Bancos de dados e navegadores#

PostgreSQL 16 e MySQL 8.0 vêm pré-instalados com seus serviços desabilitados no boot, então eles ficam fora do caminho até que um job os solicite. Iniciar o que você precisa é um passo de uma linha, e é gerenciamento padrão de serviços do Ubuntu, não algo específico do Latchkey:

Inicie o serviço antes dos passos que o usam:

.github/workflows/ci.yml

steps:
  - uses: actions/checkout@v4
  - name: Start PostgreSQL
    run: sudo systemctl start postgresql
  - run: npm test

O mesmo padrão para MySQL 8.0:

.github/workflows/ci.yml

steps:
  - uses: actions/checkout@v4
  - name: Start MySQL
    run: sudo systemctl start mysql
  - run: npm test

Chrome, Firefox e Edge vêm pré-instalados com versões de driver correspondentes, e o Selenium está disponível, então a maioria das suítes de teste de navegador roda sem passo de instalação algum. Para trabalho mobile, o Android SDK e NDK também estão na imagem.

Iniciar serviços dentro do job também mantém a dependência explícita: qualquer um que leia o arquivo de workflow pode ver que a suíte precisa de um banco de dados, o que vale a pena ter quando um workflow se move entre tipos de runner.