build/bake: BuildKit secrets support

[crazy-max]

fixes #40
closes #239

This adds BuildKit secret support to the build and bake reusable workflows through a shared build-secrets workflow secret.

The new build-secrets secret accepts a YAML object that maps BuildKit secret IDs to secret values. Secret IDs may contain letters, digits, underscores, and dashes. The build workflow parses that YAML and forwards each entry to docker/build-push-action through secret-envs.

The bake workflow uses the same unqualified key contract and scopes those entries to the workflow target input. It also accepts Bake-only target-scoped keys in the form target.secret_id, which appends target.secrets+=id=...,env=... overrides for docker/bake-action instead of using a broad wildcard override. This replaces existing same-ID Bake secret sources when they are already declared for that target.

A caller can pass a literal multiline secret with YAML block syntax.

secrets:
  build-secrets: |
    npmrc: |
      //registry.npmjs.org/:_authToken=token
      always-auth=true

A caller can also pass GitHub secrets through toJSON(...) so multiline values and YAML-sensitive characters are preserved.

secrets:
  build-secrets: |
    npmrc: ${{ toJSON(secrets.NPMRC) }}
    release.aws_credentials: ${{ toJSON(secrets.AWS_CREDENTIALS) }}

Reusable workflows cannot accept arbitrary dynamic secret names, so this keeps the public contract stable while still allowing callers to provide any BuildKit secret ID they need.

The workflow does not accept file paths as secret payloads. Bake targets can still declare file-based secret sources for local docker buildx bake usage, and matching build-secrets entries override those sources with env-backed workflow-provided values during the reusable workflow run.

[tonistiigi]

Are these setOutput calls really safe?

[crazy-max]

I changed this so secret-bearing env values are exported with core.exportVariable(...) instead of being serialized through core.setOutput('envs', ...). The later env: ${{ fromJson(steps.prepare.outputs.envs || '{}') }} plumbing is gone from both build steps.

secret-envs remains an output in build.yml, but that only contains secret_id=ENV_NAME mappings, not secret values.

[tonistiigi]

Why is this adding secrets to the definition? I would think secrets need to be defined already and just values are loaded here.

[crazy-max]

I dug into this more and I think the secrets+= override is intentional here.

For Bake, target.secret defines both the BuildKit secret ID and the source for that secret. If a caller has secret = ["id=foo,env=MY_FOO"], only exporting another env var from the workflow does not change what Bake uses. Using *.secrets+=id=foo,env=<internal env> replaces the existing same-ID secret source instead of duplicating it, which I verified with buildx bake --print.

That keeps the reusable workflow contract as build-secrets: { foo: value } and avoids making callers reference github-builder internal env names in their Bake files. It also lets existing Bake targets keep local sources for direct docker buildx bake usage, while the reusable workflow overrides those sources when a matching build-secrets entry is provided.

I updated the docs to avoid saying file-based secrets are supported as workflow payloads. The workflow still accepts secret values only and exposes them to BuildKit from env vars. A Bake target can still declare a file source for local use, for example type=file,id=aws,src=${HOME}/.aws/credentials, and the reusable workflow overrides that source when build-secrets contains aws.