image-cache

原文涵盖的主题

• Image cache on ghcr.io
• Access
• Which shape
• Reference

A cloud session starts with an empty Docker cache, so every image builds from scratch. The owner's ghcr.io namespace is the shared cache: one session writes it, the next reads it. and below are the GitHub owner and name of the repo being built, lower-cased (git remote get-url origin). The egress proxy logs every ghcr.io request in as the owner (a token with read:packages and write:packages, injected as Authorization: Bearer ). Pull and push with plain docker; GITHUBTOKEN and GHTOKEN hold placeholders, so a docker login would only send the wrong credential. Check it first: curl -s -o /dev/null -w '%{httpcode}' https://ghcr.io/v2/ answers 200. A 403 with invalid token means the environment's ghcr.io secret is wrong (a raw token instead of its base64): a You: item for the owner, not something to work around. Layer cache (the default, for an image the repo builds): BuildKit reads and writes the cache beside the build, so nobody pushes by hand and a changed input simply misses. Add to the repo's single build entry point, per image: --cache-from type=registry,ref=ghcr.io/ / / :buildcache --cache-to type=registry,ref=ghcr.io/ / / :buildcache,mode=max,ignore-error=true. mode=max keeps the

这里只展示节选，请以完整原文和当前要求为准。