feat(docker-build-image): support separate docker cache registry and buildKit config

[NikitaCOEUR]

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:

• The ability to use a separate registry for Docker build cache (with authentication),
• Inline configuration of the BuildKit daemon,
• Improved handling of Docker cache image naming.

---

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.io as 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.io for 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, and cache-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-action step to authenticate with the cache registry when it is specified, allowing secure access to cache storage.

---

BuildKit configuration improvements

• Introduced a new buildkitd-config-inline input 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

• Replaced command -v docker with which docker when checking for Docker availability. When executed via await exec.exec('command -v docker', { stdio: 'ignore' });, the command did not correctly detect that Docker was already installed on the runner. Switching to which docker resolved this issue and allowed Docker to be reliably detected in this execution context.

[github-actions]

Hi, thank you for creating your PR, we will check it out very soon

[NikitaCOEUR]

Hi @neilime, could you take a look when you have time?