4 ms·

Can you link to this bug? I thought .dockerignore specifically didn't allow whitelisting and only allowed for blacklisting files that weren't to be included. A

Can you link to this bug? I thought .dockerignore specifically didn't allow whitelisting and only allowed for blacklisting files that weren't to be included. Are you saying that docker would include files that should have been excluded by .dockerignore? I'd be interested to learn more. Thanks in advance.

Estragon 11y ago
You could probably whitelist with a .dockerignore like * # exclude everything !README.md # include the README. !run.sh # include the initiation script You would want to check exactly what the globbing rules are for the .dockerignore file, though. I don't know whether '*' will catch .dotfiles, for instance. https://docs.docker.com/engine/reference/builder/#dockerignore-file https://golang.org/pkg/path/filepath/#Match
- hinkley 11y ago
  That's it, thanks for following up in my absence. There are a couple of frameworks where all of the production files end up in, for instance /dist and one other directory. Rather than having to constantly blacklist everything you just say "ignore everything except X and Y"
hinkley 11y ago
I'm sorry, things got hectic and I bailed on the discussion. I thought I had a handy link to the bug I was thinking of, but I couldn't find a back-link from the issue I'm watching to the one in docker/docker. I think but am not 100% certain this is the issue I was thinking of, but it seems the most likely, and it was just fixed in 1.10: https://github.com/docker/docker/issues/17911 https://github.com/docker/docker/issues/17911 Some day I'm sure .dockerignore will be solid, but my confidence level isn't high enough yet (it's getting there) to base my trust on. My point was that there are other ways that directory structures and what is visible to COPY could have played out where vigilance is less of a problem. It's usually immediately obvious if a file you actually needed is missing from a build, but less obvious that a file that you categorically did NOT want to be there is absent. Because the system runs in one of those scenarios and dies conspicuously in the other.

Estragon 11y ago

You could probably whitelist with a .dockerignore like * # exclude everything !README.md # include the README. !run.sh # include the initiation script You would want to check exactly what the globbing rules are for the .dockerignore file, though. I don't know whether '*' will catch .dotfiles, for instance. https://docs.docker.com/engine/reference/builder/#dockerignore-file https://golang.org/pkg/path/filepath/#Match

hinkley 11y ago
That's it, thanks for following up in my absence. There are a couple of frameworks where all of the production files end up in, for instance /dist and one other directory. Rather than having to constantly blacklist everything you just say "ignore everything except X and Y"

hinkley 11y ago

I'm sorry, things got hectic and I bailed on the discussion. I thought I had a handy link to the bug I was thinking of, but I couldn't find a back-link from the issue I'm watching to the one in docker/docker. I think but am not 100% certain this is the issue I was thinking of, but it seems the most likely, and it was just fixed in 1.10: https://github.com/docker/docker/issues/17911 https://github.com/docker/docker/issues/17911 Some day I'm sure .dockerignore will be solid, but my confidence level isn't high enough yet (it's getting there) to base my trust on. My point was that there are other ways that directory structures and what is visible to COPY could have played out where vigilance is less of a problem. It's usually immediately obvious if a file you actually needed is missing from a build, but less obvious that a file that you categorically did NOT want to be there is absent. Because the system runs in one of those scenarios and dies conspicuously in the other.