Distributed runner mapping is too strict

[Jazzinghen]

Description

Currently the code assumes that the available runners are called:

• ubuntu-24.04
• ubuntu-24.04-arm

However it is possible for users to have differently named runners (e.g. in case they pay for different runners). Would it be possible to configure which runner should be used for which target platform?

[crazy-max]

I think supporting configurable runner mapping is reasonable, but I would avoid making this a generic runs-on escape hatch.

The current implementation is too strict because it assumes only ubuntu-24.04 and ubuntu-24.04-arm, which does not fit GitHub-hosted larger runners that use different labels. Supporting those cases makes sense.

What I would not want here is allowing arbitrary runner labels, especially anything that could route jobs to self-hosted runners. Even if the reusable workflow still controls the build steps, the caller would then control the machine those steps execute on, which weakens the security and isolation posture of these workflows.

My preference would be to keep the contract GitHub-hosted only, and solve this with a constrained mapping model rather than a free-form runner input. For example, auto / amd64 / arm64 could map to configured allowlisted labels or groups that are still known to be GitHub-hosted.

If we ever want to support weaker trust modes later, that should probably be an explicit opt-in with clear documentation, not a transparent extension of the current behavior.

[kimdre]

I need this too. I'm building images for riscv64 and it takes ages using the currently available runner setting.
I would like to be able to use the riscv runner provided by RISE: https://github.com/apps/rise-risc-v-runners-personal

[shanduur]

+1 on this, that's quite important

[crazy-max]

Started to work on it: #188

Docs: https://github.com/crazy-max/docker-github-builder/tree/runner-select#runner-mapping

[jervi]

What I would not want here is allowing arbitrary runner labels, especially anything that could route jobs to self-hosted runners.

I'd argue that supporting self hosted runners (in other words, supporting arbitrary tags) would be great. Right now we need to create and maintain our own internal reusable workflows to support building multi arch images in a native way. It would be great to be able to use this workflow instead. But Github Hosted runners are a strict no-go for us. We must use our own runners in order to access company internal resources, artefact storage etc.

[crazy-max]

Thanks for your feedback @jervi

I think supporting self-hosted runners is a reasonable ask, but I would treat it as an explicit opt-in rather than the default contract.

The current PR is focused on GitHub-hosted runner mapping first, for example larger runners or differently named hosted labels. That keeps the existing default posture intact while solving the immediate label-mapping problem.

For self-hosted runners, I agree there are valid use cases, especially native architecture runners and environments that need private network access. BuildKit still runs the build in a sandbox, so self-hosted runners do not automatically expose host files or arbitrary runner state to the build. Any required credentials or build inputs still need to be provided explicitly.

That said, self-hosted runners do change the trust profile because the workflow steps, Docker daemon, BuildKit runtime, host kernel, network path, local storage, and cache state all execute on caller-managed infrastructure rather than GitHub-hosted infrastructure. The reusable workflow still controls the build steps, but it no longer controls the underlying machine those steps run on.

With GitHub-hosted runners, the underlying runner images and software stack are public and managed by GitHub, and each job gets a fresh environment. That gives downstream consumers a more consistent and inspectable supply-chain story. With self-hosted runners, the machine configuration, patch level, daemon settings, preinstalled tools, network policy, and persistence model are defined by the caller. That may be exactly what some users need, but it's not equivalent to the current default posture.

So my preference would be to keep this issue scoped to GitHub-hosted runner mapping, then add self-hosted support later as a deliberate opt-in if we want to support that use case. That way the docs can clearly explain the weaker/different trust guarantees instead of silently mixing both modes under the same contract.

[jervi]

Thanks for the reply, @crazy-max! That makes sense, and thank you for also recognizing our use case 😅 (btw all our self hosted runners are ephemeral, so for us security isn’t that big of an issue, but I see how it could be for other users)

[crazy-max]

Released: https://github.com/docker/github-builder/releases/tag/v1.8.0

@jervi Feel free to open a new issue for the self-hosted runners case.

[kimdre]

I created an issue because I also need this feature: #191