This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-12
Channels
- # aleph (61)
- # announcements (2)
- # babashka (65)
- # beginners (64)
- # calva (2)
- # clerk (1)
- # cljsrn (1)
- # clojure (60)
- # clojure-austin (7)
- # clojure-europe (13)
- # clojure-italy (2)
- # clojure-losangeles (4)
- # clojure-nl (2)
- # clojure-norway (94)
- # clojure-romania (2)
- # clojure-uk (7)
- # clojuredesign-podcast (5)
- # clojurescript (3)
- # core-typed (2)
- # datomic (42)
- # docker (24)
- # emacs (10)
- # exercism (50)
- # graphql (83)
- # honeysql (25)
- # hyperfiddle (12)
- # malli (13)
- # membrane (49)
- # off-topic (50)
- # podcasts-discuss (1)
- # re-frame (3)
- # reagent (12)
- # reitit (5)
- # releases (2)
- # remote-jobs (8)
Status update: Still working on JDK 21 images. I'm looking into adding Debian bookworm variants too, and possibly making that the new distro default since Ubuntu is becoming less and less appropriate for Docker images. An LTS bump is a once-every-two-years opportunity to make such a jump.
Should the default distro be the regular upstream debian image or the -slim
variant? I almost always use the -slim
ones personally, but I also always specify every aspect of the image in my Docker tags in production, so I don't really care what the default is. I tend to think of the defaults as "what gets you to your goal the fastest when tinkering or running one-liners at the shell" so have tended to lean towards batteries-included in those images.
Personally, I use slim in build stage to produce an uberjar/jar and then Clojure-less JDK image for the final image but in CI I tend to use the non-slim variants
yeah, I think that's fairly common. I'm leaning towards keeping defaults non-slim so you don't get surprised by missing packages in these "quick n' dirty please just work" use cases that the defaults are targeted at
Will the tag be clojure:temurin-21-tools-deps
(we are currently using the -20-
version of that)?
Looks like that's jammy
today (for the -20-
version)...
that will be a tag, yes. but it will move you from Ubuntu jammy to Debian bookworm
if you want to stick w/ jammy you can use clojure:temurin-21-tools-deps-jammy
'k... we deploy to centos and I dev on ubuntu (20, not 22). Can't remember what distro @U0NCTKEV8 works with for dev. But I doubt the ubuntu/debian switch in CI would matter to us. Thanks.
yeah I'm hoping it will be transparent to most of those it catches by surprise 🙂
speaking of which, better write a message to clojure google group...
(maybe redhat... which is basically centos... so, yeah, switching CI is unlikely to have any impact)
Once @quantisan has a chance to review and approve (or suggest changes that I implement, etc.), this will open a PR w/ the Docker official images folks automatically on merge.
Of course others should feel free to review and provide feedback too! The build system has gotten a bit unwieldy over the years. Of course every assumption I originally made of things we wouldn't want to vary has been broken (base image, base distro, etc.). So there's a lot of special-casing in there to create so. many. docker. tags. 🙂
Thanks @U04V70XH6!
just merged
looks like I need to remove the JDK 20 variants now, as I suspected I might. these non-LTS versions drop off the supported list once the next one comes out. the images that are already up there won't disappear from Docker Hub, but neither will they receive any more updates. so their use is discouraged.
Interesting. I didn't know they were quite so aggressive about non-LTS versions on Docker...
yeah... and the extra fun part is the upstream tags don't disappear either. so the most reliable way I've found to know when they've deprecated one is to throw a PR at their CI haha
official images PR: https://github.com/docker-library/official-images/pull/15530
once that's approved and merged the official images will start building and appearing on Docker Hub afterwards
merged! JDK 21 images should start appearing shortly on Docker Hub