[latchkey-ops-bot]

Part of latchkey-dev/latchkey#4403. Needed before latchkey-dev/latchkey#4410 reaches prod.

Held. Not to be merged or tagged until Daniel releases it. Customers run this action as @v1, so nothing here reaches them until the v1 tag moves, and merging publishes this README on GitHub and on the Marketplace listing at once. The tag move has to land no later than latchkey-dev/latchkey#4410 reaches prod. No tag or release is created or moved by this pull request.

Problem

Once latchkey-dev/latchkey#4410 lands, the cache credentials vendor gives a Latchkey on GH job whose run is not proved to be the repository's own (a fork's job, or any pull_request_target or workflow_run job) the image mirrors without the layer cache: no pull and no push on the organization's layer cache repository.

Today the action passes no ignore-error to its --cache-to. A registry that refuses the cache export fails the build, and the action then builds again without the cache. Such a job's build runs twice and bills its minutes twice, and the retry warning names a cause (a cache repository that may not exist yet) that is not the cause.

Change

• The layer cache export becomes --cache-to type=registry,ref=<repo>:<tag>,mode=<cache-mode>,ignore-error=true. A refused or failed export no longer fails the build, so the step builds once.

• --cache-from is unchanged: BuildKit already reads a cache import it is refused as a cache miss (below).

• extra-cache-to and extra-cache-from entries are passed as given. They are the workflow's own, so the action does not change how their errors are handled.

• The retry stays for a build that fails with the cache on. Its warning is now, with N the build's real exit code:

  ::warning::Build failed (exit N) with the layer cache on; building again without it.

  That line is 84 bytes, sha256 prefix 77b407a73785c19d, as signed for latchkey-dev/latchkey#4403.

• README: the --cache-to flag in "How it works" step 3 gains ,ignore-error=true. No other wording changes.

Why this mechanism

• ignore-error is BuildKit's own registry cache exporter attribute ("specify if error is ignored in case cache export fails", default false). The export still runs and still writes the cache wherever the credentials allow it. Only its failure stops failing the build.
• On the import side, BuildKit holds a failed cache import in a lazy cache manager whose queries then return no cache, so the solve goes on cold (solver/llbsolver/bridge.go). The real-buildx suite below proves it against a registry that answers 403, so no import mechanism is added.
• Rejected: probing the registry before the build. That would mean an extra request, a credential path the action does not own, and a race with the build. Also rejected: matching the export error in the build log, which still builds twice and depends on BuildKit's wording.

What a refused export looks like after this change: BuildKit prints its own error on the "exporting cache to registry" step, the step is green, and the build ran once. cache-configured stays true. It reports that the cache flags were configured, not that the cache was written.

Tests

test/cache-tag.test.sh (stub docker, the step read out of action.yml) now has 20 cases. The stub models BuildKit by failing a refused export unless its --cache-to carries ignore-error=true, and run_step now keeps the step's exit status. New and changed cases:

• A cache export the registry refuses with 403 leaves the build green and runs it once (exit 0, one docker call, a --cache-to still passed, no retry warning).
• A failed cached build, failing with exit 7, is retried once without the cache.
• The retry warning is exactly the line above with exit 7, and it is the only warning.

On the old action.yml, 2 of the 20 fail, the defect itself: the refused export builds twice, and the old warning. Eight mutations of the fix each turn the suite red: dropping ignore-error, ignore-error=false, moving it to --cache-from, dropping the export, removing the retry, the old warning text, a hard-coded exit code, and the warning without its closing period.

test/registry-refusal.test.sh (new, CI job "Cache refused by the registry") runs real docker buildx against a local registry that answers every request with 403, through a docker-container builder:

1. buildx treats a cache import the registry refuses with 403 as a miss.
2. buildx fails the build on a cache export the registry refuses, without ignore-error.
3. buildx keeps the build green on a refused cache export with ignore-error=true.
4. The step builds once and stays green when the registry refuses the cache both ways.
5. The step with ignore-error stripped builds twice, so case 4 catches its removal with the real tool.

The tests landed first on this branch. On the tests-only head cca3de1 both jobs were red: the stub suite with 18 passed and 2 failed, the real-buildx suite with 4 passed and 1 failed (the step built twice, BuildKit reporting error writing layer blob: denied). Run 42529396676. The run before it, on bf6fc4c, read a TLS error instead of a refusal, because the test builder's registry config set insecure beside http. cca3de1 fixes that.

CI

On the fix head 927c5df, both jobs are green: "Cache tag derivation" 20 passed, 0 failed, and "Cache refused by the registry" 5 passed, 0 failed. Run 42529562640.

🤖 Generated with Claude Code

https://claude.ai/code/session_015S8GLJdafAKhEFyWk5HdjB