add registry-login input for optional registry auth before build

[crazy-max]

• fixes Allow registry auth for local output #97
• fixes Docker 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.