feat(docker-build-image): support separate docker cache registry and buildKit config #648
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…pport Add new inputs to support: - cache-registry: separate registry for Docker build cache - cache-registry-username/password: credentials for cache registry - buildkitd-config-inline: custom BuildKit daemon configuration When cache-registry is specified, the cache image path is automatically constructed using this registry instead of the main oci-registry. This allows using a local/private registry for build cache while pushing final images to a different registry (e.g., ghcr.io).
Contributor
|
Hi, thank you for creating your PR, we will check it out very soon |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request introduces enhanced support for Docker build cache management and BuildKit configuration in both the reusable workflow (
.github/workflows/docker-build-images.yml) and the composite action (actions/docker/build-image/action.yml).The main improvements include:
Context
We use self-hosted runners to execute our CI jobs and rely on an internal registry to speed up Docker image builds. However, we still use
ghcr.ioas the final registry for storing application images.These changes are required to allow the internal registry to be used for CI images and BuildKit cache images, while continuing to push the final application images to
ghcr.io.To achieve this, BuildKit must be configured to store its cache layers in the internal registry, while still targeting
ghcr.iofor the final images. This requires authenticating against two different Docker registries during the workflow execution.Docker build cache and registry enhancements
Added new inputs to both the workflow and the action to allow specifying a separate
cache-registry,cache-registry-username, andcache-registry-password. This enables storing Docker build cache in a different registry than the final image, which is useful in multi-registry setups.Updated the action logic to build the cache image name using the separate cache registry when provided, ensuring correct image naming for cache operations.
Added a
docker/login-actionstep to authenticate with the cache registry when it is specified, allowing secure access to cache storage.BuildKit configuration improvements
buildkitd-config-inlineinput in both the workflow and the action. This allows inline configuration of the BuildKit daemon (for example, to support insecure registries), and passes this configuration directly to the BuildKit setup step.Fixes
command -v dockerwithwhich dockerwhen checking for Docker availability. When executed viaawait exec.exec('command -v docker', { stdio: 'ignore' });,the command did not correctly detect that Docker was already installed on the runner. Switching towhich dockerresolved this issue and allowed Docker to be reliably detected in this execution context.