Allow environment variables to be injected into the docker build map

[ejschoen]

Thanks for taking my last pull request. This one's just slightly more interesting. We want our docker containers to be tagged with some build number information, as coming from Jenkins' BUILD_NUMBER environment variable for example. This way, we can tag containers with both project-name:version and project-name:version-build. Our CD pipeline picks the latest docker images labelled against the desired branch and tagged with a tag that matches a "major.minor.patch-build" pattern, and sends updated name:tag values to Helm, to perform a rolling update on our K8s cluster. When we're happy with the state of a container, we push it out for use, without the -BUILD number part of the tag.

So... this change adds the ability to have something like this in the :docker configuration:

:docker {:image-name "myregistry.example.org/myimage"
         :tags ["%s" "%s-${BUILD_NUMBER:-unknown}"]}

The syntax is similar to the way one dereferences a variable in bash with defaulting. The resulting container will be tagged with the version number and with the version number and build number appended. If used in a context where the environment variable is not defined, the default is used. If there is no default, an empty string is substituted.

For completeness, environment variables can be injected into :image-name, :version, :dockerfile, and :build-dir in the :docker configuration map.

[chrisbetz]

Hi,

sorry, I'm a little busy right now and did not yet had the time to look into this. However, I'd like to share my two cents with you.

First: The general idea is correct, you should be able to parameterize the tags from your build environment.
Second: I'd really love to see the same mechanism in different places. So, for environment variables in leiningen there already are two different mechanisms: One is utilizing expressions like :env/archiva_username for the credentials to repositories and another one is to execute arbitrary code in leiningen on any place of the project definition by using the ~ unquoting mechanism as shown in Bits Abound: Leiningen and Environment Variables. You're about to introduce a third mechanism here with the $ expressions. So maybe it would be better to use something like this ~(str "%s-" (or (System/getenv "BUILD_NUMBER") "-unknown") in the first place without altering lein-docker.

However, I'm still undecided on this as I need some time to actually design that stuff. Just wanted to give you feedback on where I'm standing right now wrt this PR.

Thank you very much for creating the PR, as this is a major point of point obviously and the Leiningen unquote mechanism is not well documented and well known. So the very least to come out of this PR will be an addition to the README.

What do you think on my points?

Happy hacking,

Chris

[ejschoen]

I didn’t know about Leiningen’s unquote. It would certainly work, and would achieve my goals. However, the phrase “arbitrary code execution” raises all sorts of red flags for me from an IT security perspective.