Open
Description
Description
Better support a git repo as remote context would be ideal with the ability to:
- Adjust the implicit
Dockerfile
default to another filename (presently only supported via different sub-directories or slightly different--file
input?) - Use the
.dockerignore
(which would be applied prior to using a shallowgit clone
as build context?)
Current situation:
# git URL context => Clones repo into a build context (local or repo `.dockerignore` is not applied)
# `--file` option provides HTTPS URL to select different Dockerfile variant
docker build \
--tag localhost/project-name:branch-or-tag \
--file https://raw.githubusercontent.com/user/repo/branch-or-tag/Dockerfile.alpine \
https://github.com/user/repo.sh.git#branch-or-tag
Proposed:
# --ignore should technically not be required to use `.dockerignore`
# from the remote context unless choosing to opt-out via `/dev/null`?
docker build \
--tag localhost/project-name:branch-or-tag \
--file context://Dockerfile.alpine \
--ignore context://.dockerignore \
https://github.com/user/repo.sh.git#branch-or-tag
Additional reference
Remote build contexts and Dockerfile
(either implicit via remote context, or explicit via separate --file
arg) are supported but not remote .dockerignore
files (or even custom path locally).
- When looking into using remote contexts and a non-default
Dockerfile
file name, I was curious if I could perform a build with a singledocker build
command and references to a repo on Github, but noticed the larger image from lack of.dockerignore
being applied to the build context (which I later noticed is also the case if this file exists locally). - The official docs still imply
.dockerignore
would be supported when it exists in the build context root, but is incorrect and needs to update the docs. - Additional build-context args are supported via CLI, but not one for overriding the default via path value instead of hard-coded filename patterns?
Related:
- Buildkit ignores .dockerignore in Git repository #2353 (comment) (
.dockerignore
doesn't work for remote build contexts, even when it exists locally) - Remote Dockerfiles #3121 (comment) (original comment of mine as motivation for feature request)