add registry-login input for optional registry auth before build

[crazy-max]

• fixesAllow registry auth for local output #97
• fixesDocker Login not just for push? #116

This PR adds a registry-login input to both reusable workflows to control whether registry login happens before the build step. The input supports auto, true, and false:

• auto preserves the current behavior and enables login only when output=image and push=true
• true always attempts a pre-build login
• false disables pre-build login

This makes pre-build registry authentication available for cases such as local output or non-push builds, while keeping the default behavior unchanged.

[tonistiigi]

I'm not sure why this isn't the default.

If this is to prevent early login for public pull then that could be handled with the scope property.

If this is needed, then why isn't it in registry auth config, per-registry?

[crazy-max]

I'm not sure why this isn't the default.

If this is to prevent early login for public pull then that could be handled with the scope property.

If this is needed, then why isn't it in registry auth config, per-registry?

Good point. I tested this and registry-auths presence is not a safe signal: on fork PRs the YAML can still be non-empty while secret values inside resolve to empty, so login fails. scope is useful per-registry, but it doesn't solve event/fork gating. For that reason I kept registry-login explicit (default auto to preserve current behavior), and callers can opt-in with a fork-safe condition like:

registry-login: ${{ github.event_name != 'pull_request' || !github.event.pull_request.head.repo.fork }}

This is similar to what we do in our repos like https://github.com/moby/buildkit-bench/blob/0ba0908a5f906bc469d6ebdca9731942432c81c9/.github/workflows/ci.yml#L81 but here we gate the login-action.

Alternatively we would have a new skip attribute in registry-auths yaml object like:

secrets:
registry-auths: | - registry: docker.io username: ${{ vars.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} skip: ${{ github.event_name = 'pull_request' }}

Or enable:

secrets:
registry-auths: | - registry: docker.io username: ${{ vars.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} enable: ${{ github.event_name != 'pull_request' }}

WDYT?

[tonistiigi]

Alternatively we would have a new skip attribute in registry-auths yaml object like:

Or just skip automatically if "password" (or any other credential method) is empty?

[crazy-max]

Alternatively we would have a new skip attribute in registry-auths yaml object like:

Or just skip automatically if "password" (or any other credential method) is empty?

If we have OIDC in play in the future, password would always be empty but I guess there would be some special handling for username in this case like <user>:<connection_id> so yeah maybe that works to skip if password is empty but should be opt-in on login-action with an env imo.

[crazy-max]

Alternatively we would have a new skip attribute in registry-auths yaml object like:

Or just skip automatically if "password" (or any other credential method) is empty?

If we have OIDC in play in the future, password would always be empty but I guess there would be some special handling for username in this case like <user>:<connection_id> so yeah maybe that works to skip if password is empty but should be opt-in on login-action with an env imo.

Opened docker/login-action#925

[crazy-max]

Ok after thinking more about it, I think this should stay explicit in github-builder. The need to skip login on fork PRs is workflow/event policy, not really registry auth schema. scope is orthogonal here, and registry-auths presence is not a reliable signal because the YAML can still be non-empty while embedded secrets resolve empty. So my preference is to keep registry-login as auto|true|false: auto preserves current behavior, true forces pre-build login and fails on missing creds, false disables it. Users that want fork-safe behavior can express that at the caller side with an explicit condition.

[tonistiigi]

and registry-auths presence is not a reliable signal because the YAML can still be non-empty while embedded secrets resolve empty.

I'm not sure I understand this. If the whole block is empty then no login. How would the login even be possible anyway in this case.

So my preference is to keep registry-login as auto|true|false: auto preserves current behavior, true forces pre-build login and fails on missing creds, false disables it.

If the whole definition is defining if login should happen before build or after then how is this different from scope? Pull scope means pre-build (even on local output)?

[crazy-max]

I'm not sure I understand this. If the whole block is empty then no login. How would the login even be possible anyway in this case.

Ok to clarify the "non-empty YAML but empty creds" case: callers usually pass a literal YAML block in secrets.registry-auths, for example:

secrets:
registry-auths: | - registry: docker.io username: ${{ vars.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }}

On a fork PR, ${{ secrets.DOCKERHUB_TOKEN }} resolves empty, but the YAML block itself is still present and still parses as an auth entry. So registry-auths being non-empty is not a reliable signal for whether early login should happen.

If the whole definition is defining if login should happen before build or after then how is this different from scope? Pull scope means pre-build (even on local output)?

For scope, I think that's the wrong abstraction for this switch. The problem here is workflow timing/policy: should we run a login step before the build or not, including for output=local / push=false. registry-login expresses that directly at the workflow level and keeps the default behavior explicit: auto preserves current behavior, true always attempts pre-build login, false disables it.

Using scope for this would mix step timing into the auth object itself. scope is per-registry auth metadata, while this is a workflow-level decision about whether an early login phase exists at all. That is why I think registry-login is the clearer layer for this.