Ignoring .dockerignore

docker

#1

My .dockerignore is being ignored and it’s driving me crazy. My docker file has the following COPY statement

WORKDIR /gg-dash
COPY . /gg-dash

…and after I do a RUN ls -l just to see what got copied.

My .dockerignore file (in root next to Dockerfile) has the following statements:

**/.DS_Store
dist
node_modules
splash
.resin-sync.yml
local.sh
README.md

…but I’m still getting everything copied (including .git) - Am I doing something wrong here?

Cheers,
Chris


#5

Hey @chrisallmark this is because .dockerignore files are not supported on the resin build servers. I will raise this item for discussion and update this thread after this.


#8

Cool. Thanks for the update.


#9

I second this request! Would love to see this also on cli build feature (i.e., resin build).


#11

The .dockerignore seems to be ignored for me during resin local push builds, as well. Is that the case?

It’s mentioned in documentation but I keep ending up with explicitly ignored files on the host. .resin-sync.yml and --ignore don’t work either.


#12

Dev Machine:
2018 15" MBP
macOS 10.13.6
node 10.10.0
Docker version 18.03.1-ce, build 9ee9f40
resin cli 7.9.3

Target Machine:
raspi 3 b+
Resin OS 2.15.1+rev1

Ignoring doesn’t seem to work at all, in any situation. PLEASE HELP @CameronDiver !

For example I’m working on a node project for raspi3. Both .gitignore and .dockerignore have a single line for node_modules.

If I have a node_modules directory on my dev machine (which I have to use different dev dependencies during development) and I run any of the following:

  • resin push appName -c
  • sudo resin local push --source . -f
  • resin deploy appName --build

The node_modules from my dev machine gets copied to my raspi3 (I know this because I’m dependent on some packages that need to be of a certain architecture… onoff etc) and my container fails to run with errors.

HOWEVER. If I rm -rf node_modules before I run any of the above commands then things seem to work perfectly. Heretofore ignoring files doesn’t work. Not with gitignore. Not with dockerignore. And the documentation on resin.io talks about using dockerignore multiple times (eg https://docs.resin.io/learn/deploy/build-optimization/#use-dockerignore). This should work!

Edit: I also tried doing an update through git push resin master and that did not heed dockerignore either. I think this wouldn’t be such a big deal if it wasn’t in the docs (a couple times) that dockerignore does something. Maybe for now remove it from the docs?


#13

@chachi @johnslemmer we have recently implemented this here: https://github.com/resin-io/resin-cli/pull/950

We are adding a lot of changes to the build infrastructure, some of them breaking changes (such as the above). For that reason we are collecting them together, and will release a v8 of the CLI soon. If you prefer, you can check out the v8-meta-branch git branch that these changes were merged to, and use them in a beta form.

Note that the ignore files will be respected on resin build, and resin push. For now, resin local push will not respect them, but that support is also coming.

Let me know if you run into any problems using this branch!


#14

@CameronDiver I think this PR has a side effect since there does not seem to be a way to whitelist a file in .dockerignore but blacklist it in .gitignore when using balena build.

I am building a Docker container locally with balena build and deploy it with balena deploy since we cannot push our source code to you.

For the balena build step I need a .tar.gz file from a private Google Bucket which I can copy with gsutil cp ... into the current directory. I would like to use this file inside the Docker context but not check this into git. So it must be in .gitignore.

Since the cli excludes all files that are either in .gitignore or .dockerignore I don’t see how I can make this work. There would need to be an option to have balena build only use .dockerignore.


#17

Additionally, I also have to temporarily remove all .gitignore files in subfolders to make balena build work correctly. I have a Go project with a vendor folder for all third-party libraries. This also contains .gitignore files. If I don’t delete the files some files will not be copied into the build context and the build fails.


#20

@magiconair, thanks for reporting this. We’ve started a discussion of what the most appropriate treatment of the .*ignore files should be and I have opened a balena-cli issue:

I understand your example that “for the balena build step I need a .tar.gz file from a private Google Bucket which I can copy with gsutil cp ... into the current directory” – it’s easy to see how this file should be listed in the .gitgnore file, yet should be uploaded for the docker image build.

But I am less clear about your other example, of having to remove the .gitgnore files from subfolders including the Go vendor folder. What kind of files are present in those subfolders that should be uploaded for the docker image build, yet not committed with git? The reason for asking this question is that the better we understand the problem, the more likely we are to come up with a good solution!

Thanks again.


#23

@pdcastro Thanks for asking. Looks like I was chasing a ghost with the vendor problem. Only the .gitignore problem is still there. If the other one pops up for a different reason, I’ll let you know.


#26

@pdcastro Looks like I was not chasing a ghost. See https://github.com/balena-io/balena-cli/issues/1032#issuecomment-441816020. I’ve created a sample project to demo this.


#29

Thanks for this @magiconair - it has certainly sparked a lot of internal discussion as to the best way to handle this and we plan to make some changes soon.

For a bit of context, the reason that it was done this way was when we added balena push <appname> as an alternative to git push balena master that doesn’t require an SSH key to be added etc. The decision was taken that the behaviour should match git push as much as possible but it’s revealed problems such as the above that weren’t immediately obvious.

We definitely appreciate you bringing this up, and creating a test case etc!