Bug Report: wrong elixir version installed in cimg/elixir v1.16.x and v1.17.x

[lwld]

Describe the bug

All cimg/elixir images tagged with patch versions of 1.16 and 1.17 contain the wrong elixir version (patch .0 instead of what is tagged):

• images tagged with 1.16.1, 1.16.2, 1.16.3 contain elixir version 1.16.0
• images tagged with 1.17.1, 1.17.2 contain elixir version 1.17.0

It seems that the elixir version was never updated when these images were published.

Images tagged with 1.15.8 are still correct, they contain elixir version 1.15.8.

Tested with -erlang-26.2.1 images.

To Reproduce

Minimal sample project that reproduces the issue: https://github.com/Kittysplit/cimg_test
The build results on commits show which tag versions are correct and which aren't: https://github.com/Kittysplit/cimg_test/commits/main/

Sample config:

version: 2.1

workflows:
  check:
    jobs:
      - compile

jobs:
  compile:
    docker:
      - image: cimg/elixir:1.17.2-erlang-26.2.1
    steps:
      - checkout
      - run:
          name: "Check elixir version"
          command: elixir --version
      - run:
          name: "Install hex"
          command: mix local.hex --force
      - run:
          name: "Install rebar"
          command: mix local.rebar --force
      - run:
          name: "Get elixir dependencies"
          command: mix deps.get
      - run:
          name: "Build elixir"
          command: mix compile --warnings-as-errors
      - run:
          name: "Run elixir tests"
          command: mix test

The elixir --version step output already shows that it's running the wrong elixir version:

Erlang/OTP 26 [erts-14.2.1] [source] [64-bit] [smp:36:8] [ds:36:8:10] [async-threads:1] [jit:ns]

Elixir 1.17.0 (compiled with Erlang/OTP 26)

If it contains an elixir project and the elixir version is fixed including patch version (with elixir: "~> 1.17.2"), mix compile / mix test will fail with ** (Mix) You're trying to run :cimg_test on Elixir v1.17.0 but it has declared in its mix.exs file it supports only Elixir ~> 1.17.2. See sample project linked above to reproduce.

Expected behavior

Images should contain the tagged elixir version, or higher patch version for images tagged with only a minor release (as described in https://github.com/CircleCI-Public/cimg-elixir?tab=readme-ov-file#tagging-scheme)

Workarounds

• Only use images tagged with minor version (eg. 1.17, not 1.17.1/1.17.2)
• Set elixir version without patch version in elixir: "~> 1.17", however this still doesn't use the tagged patch version.

Screenshots and Build Links

• tag: 1.15.8: ✅ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/1/workflows/a853f706-91a7-457c-835d-dd5972e42d9f
• tag: 1.16: ✅ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/2/workflows/2eb1c7a9-6f98-45f2-b8d9-5b723d4c60da
• tag: 1.16.0: ✅ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/3/workflows/2696e527-4844-4e5a-a944-16c36119647b
• tag: 1.16.1: ❌ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/4/workflows/2e47a4c8-7e52-443f-86b0-938c9e2c6d64
• tag: 1.16.2: ❌ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/5/workflows/2488b32d-0f8f-46b2-8ead-023b7f2ceb03
• tag: 1.16.3: ❌ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/6/workflows/f52426ca-1589-4709-a99d-5dbb156c62ee
• tag: 1.17: ✅ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/7/workflows/e67e96dc-586b-4427-bd74-525933848ffc
• tag: 1.17.0: ✅ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/8/workflows/806e3c7d-3b3c-4314-a059-5dc88c7b3f3d
• tag: 1.17.1: ❌ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/9/workflows/5c599e5a-45c9-44c8-b438-816a2cb98a17
• tag: 1.17.2: ❌ https://app.circleci.com/pipelines/github/Kittysplit/cimg_test/10/workflows/d1c0c41e-d3f8-4e8b-9b90-063150a01f79

Screenshots:

See elixir version in image container tag during spin up vs elixir --version output:

Error on mix compile:

Additional context
none

[tomtaylor]

This seems like a pretty big issue - is anyone at CircleCI able to look at this? Thanks! cc: @bjohnso5

[Kuret]

@bjohnso5 Any update on this? There has not been a response on this issue and the OTP27 issue for more than a month.

I know I am not obligated anything (even though we pay for and use CircleCI heavily in our organization), but not even an acknowledgement for issues on an officially supported CircleCI convenience image is disappointing to say the least.

If maintaining this is difficult or there is a lack of resources wouldn't it be preferable to drop support or hand it over to someone else in the community, so developers that prefer to be on top of version updates know not to rely on this 'convenience' image?

[Kuret]

@bjohnso5 @FelicianoTech (not sure who to tag for this) any update on this? This (and the OTP27 issue) is blocking our version updates. Once again, not even an acknowledgement is disappointing.

My colleague also made an attempt (that also got no response it seems) but just upping the versions didn't seem to work: #160

Once again, does CircleCI still plan on 'officially' supporting this image or do we have to look elsewhere? I'd rather use an official image in our CI flow...

[tomtaylor]

@Kuret it might be worth going through support to get an answer about whether this image is officially supported, and what the release schedule is. The CircleCI docs suggest this is an officially supported image, but the radio silence suggests it's on a best-effort basis. https://circleci.com/docs/circleci-images/

[tomtaylor]

FWIW, I think it wouldn't be too hard to switch to e.g. the hex.pm docker image, but we use some of the CircleCI CLI tools provided in the image and I haven't had the time to work out how to layer the two together.

[Kuret]

Their support options are kind of confusing... I tried to create a ticket through our organization but couldn't find much. I could only find a support site where I had to create a separate account (so not through my account/organization).

I created a post on their 'Discuss' page for now: https://discuss.circleci.com/t/please-clarify-your-offical-cimg-elixir-support/52212

[Kuret]

No response on GitHub
No response on their forums
No response on our support ticket. Our organization's plan says 'Prompt responses' under the support section. I'm not sure what CircleCI would define as 'prompt' but it's not in line with the general expectation.

What kind of organization is this?

@bjohnso5 or @FelicianoTech can you please get someone at CircleCI to look into this? And look into our ticket?

[FelicianoTech]

I haven't worked at CircleCI since last January. I can't help with this. Sorry.

[marboledacci]

The issue for this images should be solved now

[Kuret]

Wow, tbh I did not expect anything from this anymore. We already gave up and rolled our own image.

While it is appreciated, we were trying to get into contact with someone from CircleCI for months, using multiple support avenues. Eventually we had a planned call with Adrian Bradley who promised to get back to us the next week but we never heard back from him. It has been been a while now. We emailed him about an update a couple of weeks ago but, once again, never heard back.

In the meantime we spent time and resources to create our own image. This is not our core business or expertise (that's why we're a CircleCI customer!) so this was time that could've been spent better.

This 'support' for an officially supported image is really sub-par and unacceptable for paying customers.

Are you able to forward this to the correct person or department? We would love to get some feedback about this whole ordeal, what went wrong in the communication and how this can be improved in the future. I think, as customers, it should be easier to get in contact with someone right?

Can you give any guarantees the support for future Elixir versions will be quicker?

[lwld]

Looks good 👍

Re-checked images with Elixir versions 1.15.8 up to 1.18.2 and erlang 26.2.1 - all working correctly now.

Thanks for fixing the process / images @marboledacci and others involved 🏆

[Adrian0092]

Hi @Kuret

Firstly I wanted to apologise for dropping the ball on this after our call last year. I did take this issue to our teams internally and I found out that there needed to be some further digging done on our end to work out what had happened here. I should have let you know that we were looking into this internally but it completely slipped my mind and this is purely my fault.

As for the future, we are committed to providing convenience image support. We completely hold our hands up and admit we missed the mark in this case. We have worked to bring in new resources and expertise to make sure we can provide better support for convenience images in the future.

I'm glad this has been finally resolved but completely understand the frustration caused here by the lack of communication. We will strive to improve this and hopefully we wont run into this scenario again.

Kind regards
Adrian

[Kuret]

Hi Adrian,

Thanks for elaborating. I appreciate the response.
I'm glad you're stepping up support in the future! For some reason, our own image had some issues properly caching. (Something with timestamps I guess?) so looking forward to get back to the official images again.

For any future issues, what would be the best way to get into contact? We got on a call eventually, but I remember we tried tickets, emails, github, the forums, x.com but to no avail. Also, not everything has to be a call.

Once again thanks for your detailed reply!

(PS: This issue can be closed now, I think?)