Remote Bake file and Source Condition

Contributing guidelines

• I've read the contributing guidelines and wholeheartedly agree

I've found a bug, and:

• 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:

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:

1. Fetch and use the specified docker-bake.hcl from a remote repository.

2. 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

- name: Build and push Docker image using Docker Bake
        uses: docker/bake-action@v4
        with:
          source: https://${{ secrets.TOKEN}}@github.com/RxBenefits/<orgrepo>.git#main
          push: true

Workflow logs

No response

BuildKit logs

No response

Additional info

No response

Start with the README's source input documentation and the action behavior that handles it, then compare that behavior with the documented docker buildx bake remote-definition command. Done means a remote docker-bake.hcl can be reused while the local repository supplies its Dockerfile and build context, with the README distinguishing these modes accurately.