Fail to deploy 1.14.0 via docker

My dockerfile is using

FROM elixir:1.14 AS builder

But i am getting

** (Mix) You're trying to run :shopcash on Elixir v1.14.0-rc.0 but it has declared in its mix.exs file it supports only Elixir 1.14.0

It seems the image 1.14 is somehow tagged to v1.14.0-rc.0 and not 1.14.0. Am i right?

Can you show the rest of your Dockerfile and your mix.exs?

The elixir:
 dockerfile seems to have not yet been updated for the 1.14 release. This one, while now maintained by the EEF, is still handled manually.

I generally suggest using the hexpm docker containers, as they‘re built automatically from github releases.

4 Likes

docker run --rm -ti elixir:1.14
works just fine

but it’s using 1.14.0-rc.0 indeed! That’s likely the problem

recommend you use build from hexpm/elixir i am using
FROM docker.io/hexpm/elixir:1.14.0-erlang-25.0.4-debian-bullseye-20220801-slim

works well

6 Likes

I’ve submitted a PR to fix this: elixir v1.14.0 by adamu · Pull Request #46 · erlef/docker-elixir · GitHub

But I agree, the hexpm images are better. It’s quite a shame that the official elixir images have two big issues:

  1. No way to pin the underlying erlang version
  2. They update existing tags, potentially breaking existing deployments
2 Likes

The “official” title here doesn’t mean it’s great, but that at some point dockerhub somehow decided this repo will be it. That decision was made before hexpm provided images and the core team has always been avoiding maintaining things in third party registries. Nowadays the EEF does maintain the repo behind those docker images, but I don’t think they’ll overhaul how tags work on it.

1 Like

Pointing people to the hexpm images from the “official” repository might be useful, they certainly seem more blessed than the EEF ones :slight_smile:

I actually enjoy the elixir images. They are quire easy to upgrade, when you don’t care about a specific Erlang minor/patch or alpine version.

1.13-otp-25-alpine is what we have now and updating to Elixir 1.14 will be super simple.

Having said that, our project is still in development. When it’s in production, we’ll probably switch to a more explicit image from hexpm.

Where can we be able to access?

https://hub.docker.com/u/hexpm

1 Like

One advantage of the “official” images is that they’re built for:

  • linux/386
  • linux/amd64
  • linux/arm/v7
  • linux/arm64/v8
  • linux/ppc64le
  • linux/s390x

(well the alpine flavour only has 4 of those, but still very useful, for example for running on Raspberry Pi)

While the Hex.pm ones are built for:

  • linux/amd64
  • linux/arm64/v8

I learned after this that the official images are determined by submitting PRs to this repository:

https://github.com/docker-library/official-images/pulls?q=is%3Apr+label%3Alibrary%2Felixir

If the EEF/community wanted to make improvements, it’s possible, but it would require some coordination. One of the advantages of the hexpm images (besides the immutable nature of the images) is that they are built automatically. It seems an official docker image always requires a PR to update or add tags.

I don’t know if this is due to the new erlang version

but I’m unable to install Elixir 1.14 on the new erlang OTP just released:
otp_win64_24.3.4.5.exe

on windows server not docker thought.

C:\Apps\gwm
λ mix
{"init terminating in do_boot",{undef,[{elixir,start_cli,[],[]},{init,start_em,1,[{file,"init.erl"},{line,1211}]},{init,do_boot,3,[{file,"init.erl"},{line,909}]}]}}
init terminating in do_boot ({undef,[{elixir,start_cli,[],[]},{init,start_em,1,[{_},{_}]},{init,do_boot,3,[{_},{_}]}]})

Crash dump is being written to: erl_crash.dump...done

C:\Apps\gwm
λ