v1.0.2

Warning

Behaviour change despite the patch version. An unset cache_from or cache_to no
longer selects a registry cache — it now means no cache. If a build_and_push call in
your repo omits either input, set it explicitly before taking this bump, or that build
silently loses its cache and stops refreshing its :cache tag.

Changed

build_and_push used to substitute a default whenever a cache input was unset:

cache_from = type=registry,ref=$REGISTRY/$IMAGE:cache
cache_to   = type=registry,ref=$REGISTRY/$IMAGE:cache,mode=max

That made "no cache" inexpressible (empty selected the default, and a composite action
cannot tell "unset" from "explicitly empty"), pushed a :cache tag as a side effect of an
input nobody set, and made this wrapper behave differently from the docker/build-push-action
it wraps.

Both inputs are now passed straight through. docker/build-push-action parses them as
newline-separated lists and emits no --cache-from / --cache-to flag for an empty value,
so caching is opt-in and the wrapper matches the action it wraps.

The Set cache values step is gone entirely (−32 lines), taking the $GITHUB_OUTPUT
round-trip and six template interpolations with it.

Are you affected?

Only if a build_and_push call omits cache_from or cache_to. Callers that already pass
both are unaffected.

cache_from: type=registry,ref=${{ env.registry }}/my-image:cache
cache_to: type=registry,ref=${{ env.registry }}/my-image:cache,mode=max

Or leave them unset deliberately — worth doing on release builds, where an exported cache is
usually written and never read.

Pin to this release

uses: pubky/ci-workflows/.github/actions/docker/build_and_push@5faaf004d36bb93a204b58cf7190ffe7fbcce16f # v1.0.2

Reference the commit SHA, not @v1.0.2 and not @main.