docker-clojure
docker-clojure copied to clipboard
Combine tools.deps and Leiningen images
This is my take on #224. There are a lot of changes, so we might as well start the review and discuss the details early.
Summary:
- Leiningen and tools.deps images no longer differ in their contents. All types of images install both Leiningen and tools.deps, and both are available on the PATH (as
lein
andclj/clojure
, respectively). -
dockerfile.lein
anddockerfile.tools-deps
namespaces still exist and serve as building blocks for the newdockerfile.combined
namespace. Thecombined
namespace assembles the parts from Leiningen and tools.deps to install both in one RUN/layer. The number of overall layers in the resulting images is minimized. - Images are still separated by their primary build tool. The only difference between
lein
andtools-deps
images is their ENTRYPOINT.lein
images continue to havelein
as their entrypoint,tools-deps
continue to haveclj
.tools-deps
remain a "default" build tool, meaning that tags without build tool specified will haveclj
entrypoint. - Downloading Leiningen artifacts is now done with
curl
.wget
is no longer needed, so we don't install or purge it. - We don't provide tags that specify both Leiningen and tools.deps version. Preliminary, it is unlikely that somebody will require both to be of the precise version.
- We currently support only the latest versions of both build tools. If, in the future, we need to provide images for multiple versions of some build tool, the versions of different build tools probably won't be dot-producted. Meaning that while the version of the primary build tool is fixed, the other build tool will still be of the latest version. In any case, the code to support multiple build tool versions is not in this PR, so it can be rethought later.
-
latest
tag no longer requires a separate docker build context, and now points to the image with default JDK, distro, and build tool (temurin-21-tools-deps-bookworm
to be exact). - Generated manifest remains almost the same, except for adding new types of tags – JDK version only (
temurin-17
,temurin-22
, etc.). I don't know if not having those was intentional or an oversight. If it's the former, I can remove that. - I did some cleanup around the code in places where I had to make changes. For example, I made
cfg/build-tools
(previously:installer-hashes
) a dynamic variable, because it had to be dragged 5-6 levels through the call stack to the single place where it is actually needed. - Tests fail for now because I changed plenty of code. I'd rather fix them once we agree on the implementation.
Will be happy to iterate on the PR now or let it sit until the decision on #224 is made.