fix(linux-runner-image): bake gh CLI into the runner image

What

Installs the GitHub CLI (gh) into the Linux runner image, alongside the kubectl + helm tools it already carries, Renovate-managed via the existing linux-runner-image ARG manager.

Why

The image’s stated design is to “close the gap against GitHub’s Ubuntu hosted-runner image” so workflow steps can assume standard tooling is on /usr/local/bin. It already bakes in kubectl + helm with exactly that reasoning. GitHub’s hosted image also ships gh (install-github-cli.sh), and the repo already depends on it on tuist-linux jobs:

• release.yml’s trigger-deploy dispatches the production deployment with gh workflow run.
• preview-deploy.yml posts GitHub Deployment statuses and PR comments with gh api / gh pr comment.

Neither installs gh (nothing installs it via mise anywhere in the repo), so on the current image they fail with gh: command not found. This was caught when trigger-deploy died on exit 127, stranding a fleet-image release without a production deploy.

How

gh is pulled from the cli/cli release tarball in the same RUN layer as kubectl/helm, ARCH-aware via dpkg --print-architecture (matches gh’s linux_amd64/linux_arm64 asset names). GH_VERSION carries a # renovate: datasource=github-releases depName=cli/cli annotation picked up by the existing generic Dockerfile ARG manager, and cli/cli is added to the packageRule that routes these bumps through the fix(linux-runner-image): commit prefix (required — the release is scope-gated, so a mis-scoped bump would silently never rebuild the image) with automerge.

Rollout dependency (important)

linux-runner-image is itself a fleet image, so a release of it defers the push-deploy to release.yml’s trigger-deploy — which is the very job that needs gh. Merging this PR builds and tags the new image but cannot deploy it through the normal path until a working gh is already on the fleet. A one-time manual workflow_dispatch of server-production-deployment.yml (which goes straight to gate → build → cascade and never touches trigger-deploy) breaks the cycle: it rolls the gh-bearing image onto the fleet, after which trigger-deploy on tuist-linux works for all future cycles.

Validation

• gh release view --repo cli/cli confirms v2.93.0 and the gh_<ver>_linux_<arch>.tar.gz asset names the install relies on.
• renovate.json parses (jq); the new GH_VERSION matches the existing custom-manager regex and the fix(linux-runner-image): routing rule.

🤖 Generated with Claude Code