[a99c43f2d565504]

To not have to remember that one can not use a .dockerignore at all and instead explicitly pick the files and directories from the build context that need to be in the image.

[__float]

This is annoying and error prone if you use an interpreted language that relies on loading source files at runtime.

For a Go service? Sure, that's easy and makes a ton of sense.

[crabbone]

> This is annoying and error prone if you use an interpreted language that relies on loading source files at runtime.

That's a bit of misconception. (Not to mention terminology mish-mash) what you probably call "interpreted" is languages like Python, JavaScript or Ruby. In all these cases, the projects are supposed to be compiled into an installable package, and then that package is supposed to be installed. So, compilation step is very similar to languages like C or Go.

Regrettably, developers rarely follow the due process and "deploy" what essentially amounts to the project's source code... This has a bunch of other problems, beside the security issues with potentially copying passwords into the deployment environment. This whole process reminds me of the early days of PHP where Web was full of examples of "guest books" which taught a generation of PHP programmers to interpolate values straight from the URL request into SQL queries. And then, PHP took the blame for "allowing it".

[tstenner]

For a go service you have a multi stage build that copies just the built executable into a clean base image.