Docker can’t find the file that’s clearly there, and AI lies to me

Welcome to yet another episode of “Gabor has thoughts” where we can peek into the mundane everydays of what actually happens at a corporate job.

It’s mostly fighting Docker and AI.

Anyways, the problem I was trying to solve was that in a particular Docker image, one layer introduces a number of CVEs. That layer is about 35 lines of --mounts, printfs, add apks and a bunch of other commands concatenated into one massive command using &&s that each individually have the power to introduce a vulnerability. I need to find which one, so I need to break them up into separate commands, and thus separate layers.

As they begin with a lot of RUN --mounts, anything that gets mounted is only available for the command that the mount is in, which means I need to replace those with COPY statements so the files we need – keys, certificates – are available permanently in the image.

I replaced all mounts with copies, broke up every other command into their own layers, and started building it, only for it to fail because it couldn’t find a file. A file that was very clearly there with the right permissions (644, so everyone can read it), but still nada.

I asked chatGPT on what this could be, and its answers were:

1. check the build context – that is correct and unchanged, all source files get mounted / copied / added anyways, the files I need are in the same directory, they should get added too
2. check file name for typos – nope, it’s the same filename
3. are they hidden files or symlinks? – no, just regular files
4. check permissions – 644, everyone can read it, other files with the same permissions get copied in
5. check build behaviour, ie --link – checked, it’s there, that works for other files already
6. debug with a minimal example – I skipped this one, because I know that copying works otherwise
7. provide explicit build context path – the command already does this

None of these helped. About 5 minutes into staring at the code while pair programming, I thought: hold on... I know what’s wrong.

.dockerignore

The file types that were not copied into the image were, rightfully so, added to the .dockerignore file.

That file tells docker to skip over files when providing context to the build, so even though I’m very explicitly asking for those files to be copied, because they are listed in the ignore file, Docker says it can’t see them.

For the purposes of debugging I commented out the entires, the build succeeded, and I had an image.

I still don’t have the layers because of a different Docker bug, I think, but that’s an entirely separate issue.

More importantly, chatGPT didn’t even think to check for the presence of a .dockerignore file, even though that should have been the very first step in debugging.

Make sure you have experienced engineers on your team and you don’t rely on vibe coding too much.

Photo by Ian Barsby on Unsplash