#Honor `.dockerignore` file when running `buildDocker`
1 messages Β· Page 1 of 1 (latest)
I tried to look for how buildkit is doing it, and possibly reuse the logic. But it seems like this is private logic inside their codebase and we cannot directly call it. (Ref: https://github.com/moby/buildkit/blob/master/frontend/dockerui/config.go#L435)
we could possibly do it here in dagger codebase, but the impact would be quite broader in that case (Ref: https://github.com/dagger/dagger/blob/c16c2f8d59b793d7a032f8c90a4ab8dcf4814393/core/schema/host.go#L246)
so, instead I am isolating the change in buildDocker function. (Draft PR: https://github.com/dagger/dagger/pull/9857)
I wanted to ask if folks have suggestions/concerns regarding this approach. Also do we want to make this behavior opt-in (for backward compatibility) OR we want to introduce a new version of this API where we enable this by default.
cc @chilly blade @sage oasis
also cc @shadow moth - Justin could you please provide feedback on these changes.
uh this seems good to me
there's no reason to backwards compat this imo
i would add some tests though with some of the more complex patterns that buildkit supports, and make sure we get the right results
we want it to be actually the same, not just seems to be the same
adding tests is gonna be super important, so we don't break it in the future
yup, this is the right place π
awesome, thank you so much.
just getting back into this. Justin's inputs SGTM! π
we use buildkit frontend as is for our docker build stuff, so I was wondering why our dockerignore file is not being picked up. Digging into this, I found this commit, which was made a few months ago:
https://github.com/moby/buildkit/commit/07fe32463a8ebb839b0a556fb2248c10c190d0cb
here, we are returning nil, if bctx.context is NOT nil. I think it is a typo: https://github.com/moby/buildkit/blob/07fe32463a8ebb839b0a556fb2248c10c190d0cb/frontend/dockerui/config.go#L481
but i could be completely wrong as well (because folks would have caught this issue in builtkit if it was an issue). so i am investigating this a bit.
The reason i am digging into this is because I picked up a testcase from buildkit repo, and that is not working in our implementation.
that seems intentional, but I don't have enough context to say why....
@shadow moth, the testcase which is failing is if the user specifies Dockerfile in the .dockerignore file, it fails to do the build as Dockerfile is no longer there.
I can workaround this by not-ignoring the "requested Dockerfile" even if it is configured in .dockerignore, but that also does not seem right.
Justin, if we add the .dockerignore handling in docker build command, doesn't it mean that we still transfer those files from host-system to daemon?
halloooo sorry, looking now
hm, so
the reason this works in buildkit is that there are two local loads - one loads the dockerfile+dockerignore, and the second uses the dockerignore to load the build context
so you can't exclude the dockerfile, because it's loaded at the "same time"
what's going wrong in your pr is here: https://github.com/dagger/dagger/pull/9857/files#diff-d37ad3550b5f8d5eb769e9d27a0f3aa2ee4f9bbfa4d7849a46c93e1cdca84bf9R388-R402
there's only one dir that we use for everything i think, and we're then able to filter out the Dockerfile
two options:
- just hack, don't allow excluding the
Dockerfile(this is quick+easy+fine if you can get it working) - properly split out the local dir loads in https://github.com/dagger/dagger/blob/592cabd3997d0310801974e51e1c61ae98287666/core/container.go#L448-L451
no real preference, both are good
just hack, don't allow excluding the Dockerfile (this is quick+easy+fine if you can get it working)
I actually went this route and "un-ignored" the Dockerfile requested by the user. I need to test this more though.
I will also checkout other suggestion to see which makes more cleaner implementation.
thank you for your the pointers...
Hi @shadow moth , there is just one pending review comment that needs your confirmation, but otherwise the PR looks good to merge.
do we need a change entry for this?
yes please!
a change entry would be good
i'll look through the pr when i get a moment!
Thanks Justin. I have committed a changie entry for this.
i am looking at the docs to update them as well. (where we mention that we don't support .dockerignore files).
Justin, I also want to make sure you are aware of this that with our changes, as we discussed earlier, we ignore the files as per dockerignore file before sending them to buildkit for building,
BUT we do upload them to dagger engine I believe. While with Dockerbuild I don't think these files are uploaded at all.
β Host.directory(path: "/Users/rajatjindal/go/src/github.com/rajatjindal/dagger-test"): Directory! 0.0s
β β upload /Users/rajatjindal/go/src/github.com/rajatjindal/dagger-test from aoy9hlxsaol1hcos3bqiwphn4 (client id: bb3nf3liur5zt02yv0ctv9h9s, session id: qdw13dc7sh0jvioqm5qp42o3p) 0.0s
β β β filesync 0.0s
β β β β copy 0.0s
β foo: Foo! 0.0s
$ .build(
β β dir: Host.directory(path: "/Users/rajatjindal/go/src/github.com/rajatjindal/dagger-test"): Directory!
β ): Container! 1.0s β CPU Pressure (some): 416Β΅s β CPU Pressure (full): 403Β΅s β Memory Bytes (current): 954 kB β Memory Bytes (peak): 23 MB CACHED
β β container: Container! 0.0s
β $ .build(
β β β context: Host.directory(path: "/Users/rajatjindal/go/src/github.com/rajatjindal/dagger-test"): Directory!
β β ): Container! 0.8s CACHED
β β β Directory.withDirectory(
β β β β directory: Host.directory(path: "/Users/rajatjindal/go/src/github.com/rajatjindal/dagger-test"): Directory!
β β β β exclude: ["foo.txt", "Dockerfile"]
β β β β path: "buildctx"
β β β ): Directory! 0.0s
β β β .directory(path: "buildctx"): Directory! 0.0s
if needed, (in theory) we can add an optional argument useDockerignore file to host.Directory api, that would be false by default (to avoid making breaking change) and if enabled will honor the dockerignore file. do you think we should add that as well?
this will be tricky because when using modules you don't have such API so we'll need to add a global flag or something for this which is π¬ . IMO it's ok to leave it as-is and if users bring up the fact that context uploads are slow because of the current implementation, we suggest that the best way to overcome that performance gap and make the most out of Dagger, is to migrate their Dockerfiles to code.
thanks Marcos.