Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADDing files that may be missing #735

Closed
dreyks opened this issue Nov 26, 2018 · 4 comments · Fixed by #809
Closed

ADDing files that may be missing #735

dreyks opened this issue Nov 26, 2018 · 4 comments · Fixed by #809

Comments

@dreyks
Copy link

dreyks commented Nov 26, 2018

I have files on host that may not always be present on build time, e.g. caches. Those are tar'ed for performance, that's why I use a separate ADD argument
I know that such technique is generally discouraged as one that may produce non-deterministic builds but this is still doable with docker

ADD . caches* ./

this way in case caches.tar is present on host - its content gets untarred and placed into the image. If it's not present - nothing bad happens

when using buildkit i'm getting #19 75.18 panic: failed to copy /src-1/caches* to app/: no matches found: /src-1/caches*

@tonistiigi
Copy link
Member

Thanks for the report. Need to make sure FileOp #396 can do this weird error handling where one suboperation is allowed to fail.

On the other hand, you are right that this is discouraged and undocumented behavior. It might be even considered a bug of the old implementation. Eg. if you compare it to regular cp behavior it is BuildKit that is working correctly in this case and not the old builder.

@tonistiigi
Copy link
Member

Also, note that you can use RUN --mount for more control of accessing your data now (filters etc.). And we also have --mount=type=cache that you might actually need if you want to persist some files to speed up builds.

@dreyks
Copy link
Author

dreyks commented Nov 27, 2018

yeah just stumbled upon that doc. thanks a lot

once again I fully understand that this may not be the intended behaviour. In such case maybe it'd be enough to just add a line to the doc

@dreyks
Copy link
Author

dreyks commented Nov 27, 2018

also I think it's the * that allows docker not to fail

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants