You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation does not mention anything about my problem
There are no open or closed issues that are related to my problem
Description
| source | String | Context to build from. Can be either local (.) or a remote bake definition |
I believe there is a misunderstanding in how the docker/bake-action currently handles the concept of a Remote Bake file, or perhaps additional support for this feature is needed. The documentation describes the source attribute as the context from which to build, which can be either local (.) or a remote bake definition. However, treating the source for both repository cloning and remote bake file definitions conflates two functionalities that I argue should be distinct.
Current Implementation Issue
The current approach uses the source parameter to clone the specified repository and then searches for a docker-bake.hcl within it. This functionality aligns with the handling of a standard source context but becomes problematic when also used to specify a Remote Bake file. The fundamental issue arises because the action does not perform a true remote bake as one might expect with a command like:
Instead, it clones the repository using source. This approach not only retrieves docker-bake.hcl but also expects to find and use a Dockerfile in the same remote repository.
Expected behaviour
Our organization aims to utilize a single docker-bake.hcl file across multiple repositories to ensure consistency and efficient reuse of Docker configurations. We expect the GitHub Action to:
Fetch and use the specified docker-bake.hcl from a remote repository.
Build using the Dockerfile located locally within the repository where the GitHub Action is running, rather than the one in the remote repository.
This distinction is crucial for maintaining streamlined and centralized Docker build configurations across various projects without duplicating the docker-bake.hcl in every repository.
We want our docker-bake.hcl file to act like a reusable workflow in a sense and right now that is not possible.
Contributing guidelines
I've found a bug, and:
Description
|
source
| String | Context to build from. Can be either local (.
) or a remote bake definition |I believe there is a misunderstanding in how the docker/bake-action currently handles the concept of a Remote Bake file, or perhaps additional support for this feature is needed. The documentation describes the source attribute as the context from which to build, which can be either local (.) or a remote bake definition. However, treating the source for both repository cloning and remote bake file definitions conflates two functionalities that I argue should be distinct.
Current Implementation Issue
The current approach uses the source parameter to clone the specified repository and then searches for a docker-bake.hcl within it. This functionality aligns with the handling of a standard source context but becomes problematic when also used to specify a Remote Bake file. The fundamental issue arises because the action does not perform a true remote bake as one might expect with a command like:
docker buildx bake "https://github.com/tonistiigi/buildx.git#remote-test" --print
Instead, it clones the repository using source. This approach not only retrieves docker-bake.hcl but also expects to find and use a Dockerfile in the same remote repository.
Expected behaviour
Our organization aims to utilize a single docker-bake.hcl file across multiple repositories to ensure consistency and efficient reuse of Docker configurations. We expect the GitHub Action to:
Fetch and use the specified docker-bake.hcl from a remote repository.
Build using the Dockerfile located locally within the repository where the GitHub Action is running, rather than the one in the remote repository.
This distinction is crucial for maintaining streamlined and centralized Docker build configurations across various projects without duplicating the docker-bake.hcl in every repository.
We want our docker-bake.hcl file to act like a reusable workflow in a sense and right now that is not possible.
Actual behaviour
There is no true support for this:
docker buildx bake "https://github.com/tonistiigi/buildx.git#remote-test" --print
Right source clones instead of doing this:
docker buildx bake "https://github.com/tonistiigi/buildx.git#remote-test" --print
But the readme states that source can do both:
|
source
| String | Context to build from. Can be either local (.
) or a remote bake definition |Repository URL
No response
Workflow run URL
No response
YAML workflow
Workflow logs
No response
BuildKit logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: