Description
openedon May 30, 2024
I mentioned this in #4905 (comment), but I've since convinced myself it's actually important enough to deserve a dedicated issue.
(I want to go back and tell little baby Tianon in moby/moby#3463 (comment) that Yes, Indeed, there are use cases where you don't want submodules 😭)
A simple reproducer for the core issue is docker buildx build 'https://github.com/neurodebian/dockerfiles.git#1da9308291ad33a33447519ec1835bb3e37acebc:dockerfiles/bullseye' -- effectively, the submodules fail to clone which causes the build to fail, but neither submodule is used in the build. This is really hard to detect what the "right" answer is automatically, so I propose some way to disable the submodule / recursive cloning behavior explicitly.
I recognize there are a few issues in this specific reproducer, some of which could be mitigated in other ways, such as updating the submodules in that repository to not use git:// URLs, using insteadOf in BuildKit for known examples like this, etc, but I believe that there is a larger issue here that this behavior is automatic and not something that can be opted out of.
I believe this could also cause the build to "build the wrong thing" in some cases -- I'm not sure how much Git validates content, but I believe it would be possible to have a repository with some content at a particular path and a submodule listed in .gitmodules that points somewhere else which would show prominently in some Git interfaces (like GitHub's), but perhaps less prominently in interfaces like cgit, so would be easy to miss that there's a top-level .gitmodules that ends up replacing the directory entirely and then scratching your head wondering why the build is failing afterwards (or worse, getting a completely wrong/unexpected build).
Activity