feat(kotlin): make ARC the default runner for the Kotlin workflows

[JesperTerkelsen]

What?

Makes the self-hosted ARC runners the default for Kotlin CI and deploys. use-arc-runners now defaults to true in the workflows service repos call directly:

Workflow	Callers
pull-request-kotlin.yml	~40 repos
sonar-cloud.yml	~30 repos (main-branch code-analysis.yml)
deploy-kotlin.yml, deploy-kotlin-v2.yml	~40 repos

• Opting out: use-arc-runners: false.
• Explicit Blacksmith settings move too: use-arc-runners still takes precedence over use-blacksmith-runners. Today that's service-energy (true) and service-ocpp and changelog-monorepo (false, GitHub-hosted runners).
• Non-Kotlin workflows don't change: component-test-kotlin.yml, component-build.yml and component-service-profile-kotlin.yml keep false as their own default, and deploy-kotlin(-v2) pass the value down to them. So deploy-generic(-v2), deploy-python, the Bun and React workflows, and direct component-build callers (infra-portal, changelog-monorepo) stay where they are.

No caller changes needed. On ARC, the PR and Sonar workflows use the S3 cache when the caller passes GH_ACTION_ACCESS_KEY_ID/GH_ACTION_SECRET_ACCESS_KEY, and fall back to the GitHub cache otherwise. Today only 2 of the 78 PR and Sonar calls pass them. The choice is made once, in a workflow-level S3_CACHE env. Tailscale and the in-cluster Sonar URL still depend on the runner, not the cache backend.

Why this is safe to default

• Java: I checked every caller's java-version against its Gradle toolchain. None conflict (36 match exactly; 7 have no toolchain and use the installed JDK). This matters because the ARC image has no preinstalled JDK.
• Maven Central 429s: Gradle on the runner resolves through CodeArtifact via the runner image's init script and IRSA (actions-runner https://github.com/monta-app/actions-runner/pull/14, kube-manifests https://github.com/monta-app/kube-manifests/pull/7670).
• Gradle inside docker build: it doesn't get CodeArtifact. feat(build): keep Dockerfile cache mounts between ARC image builds #359 keeps its /root/.gradle cache mount warm between ARC builds.

Public repositories never use ARC

Every read of the input is (inputs.use-arc-runners && github.event.repository.private). In a public repo, the workflows keep today's runners, even with use-arc-runners: true. That covers library-ocpp and ocpp-emulator, which call pull-request-kotlin, and any future public repo, so they need no per-repo opt-out.

This check isn't the security boundary. A fork PR runs the fork's own workflow files and could name an ARC label directly. The boundary is the org runner group: https://github.com/monta-app/kube-manifests/pull/7727 moves every ARC scale set into the new ARC runner group, which disallows public repositories. This check keeps public repos' shared-workflow jobs on runners they can use, instead of leaving them queued.

Merge order

All 42 per-repo opt-in PRs from the sweep are merged, so this can merge now. https://github.com/monta-app/kube-manifests/pull/7727 is independent: it closes the fork-PR path to ARC, which exists today regardless of this PR.

Earlier plan, kept for reference:

1. feat(build): keep Dockerfile cache mounts between ARC image builds #359 (Dockerfile cache mounts on ARC). Without it, every deploy on ARC downloads all Gradle dependencies inside the image build.
2. A green ARC deploy through https://github.com/monta-app/service-openadr/pull/262. The deploy path hasn't run on ARC yet.
3. This PR. About 20 repos deploy production automatically on push to main, so their next production deploy after this merges will be on ARC.

Gaps

• Warm pools: each ARC runner size keeps only 1–2 warm runners on weekdays. Moving every Kotlin repo at once means more 1–2 minute cold starts until the pools are raised.
• GitHub cache from ARC is out of region, so it's slower than S3. Letting the arc-runner IRSA role read and write the cache bucket would give every repo S3 with no secrets.

🤖 Generated with Claude Code