Fix calculating `-otp-` major for Elixir #351

paulo-ferraz-oliveira · 2025-06-26T22:03:24Z

Description

We keep the previous constraint of "user-defined version as 1.19-otp-28" winning over the OTP input, but we now use the otpVersion from the installed OTP instead of the user input, which also simplifies code around regular expressions.

I have read and understood the contributing guidelines

What changes

we add process.env.NODE_ENV to allow bypassing the initial action run during tests
instead of calculating otpVersionMajor based on input and regex, we make an actual system call (sync) to determine it and use it
- the "bypass if forced" mechanism that was in place stays in place
per @wojtekmach's input, the Elixir version matching mechanism was changes to start from the detected OTP versions and iterate down until it finds a corresponding Elixir version (this "avoids" OTP master / Elixir main from becoming Elixir main and not main-otp-29, for example, when that one's out
I reduced duplicate (in nature) test for the Elixir version checks

... everything else remains the same

Version matching examples (from the tests)

OTP <26 / Elixir <1.17 results in Elixir v1.16.3-otp-25
OTP master / Elixir > 0 results in Elixir v1.19-otp-28
OTP master / Elixir main results in Elixir main-otp-28
OTP OTP-27 / Elixir 1.18.x results in Elixir v1.18.4-otp-27
OTP OTP-26 / Elixir v1.15.0-rc.2 results in Elixir v1.15.0-rc.2-otp-26
OTP 25.2 / Elixir main results in Elixir main-otp-25

paulo-ferraz-oliveira · 2025-06-26T22:04:27Z

@Schultzer, I can't invite you for a "proper" review, so I'm mentioning you to hopefully notify you.

src/setup-beam.js

paulo-ferraz-oliveira · 2025-06-26T22:08:05Z

Mind you this doesn't fix @wojtekmach's second use case where 1.19's -rc is being picked up, but I think it's a different issue (most likely, as @Schultzer mentioned, -otp-... not helping pick the proper version), so if anything we should have a second PR for that.

src/setup-beam.js

paulo-ferraz-oliveira · 2025-06-26T22:37:23Z

@wojtekmach, if this fixes the range issue (not the -rc) one feel free to merge; otherwise leave comments and I'll probably get to it tomorrow. Cheers.

test/setup-beam.test.js

wojtekmach · 2025-06-27T08:40:23Z

otp-version: "> 0" now picks the correct version. elixir-version: "> 0" still picks the RC.

I also noticed:

elixir-version: "> 0"
otp-version: master

doesn't work: https://github.com/wojtekmach/setup_beam_bug/actions/runs/15921976367/job/44910621256

unfortunately the action does not show the URL it's trying to download from.

This works though:

elixir-version: "> 0-otp-28"
otp-version: master

paulo-ferraz-oliveira · 2025-06-27T11:33:44Z

elixir-version: "> 0" still picks the RC.

Correct. I'd written "Mind you this doesn't fix @wojtekmach's second use case where 1.19's -rc is being picked up". In any case they're different problems, and I think it should be a different PR.

paulo-ferraz-oliveira · 2025-06-27T11:38:11Z

I also noticed:
elixir-version: "> 0"
otp-version: master
doesn't work: https://github.com/wojtekmach/setup_beam_bug/actions/runs/15921976367/job/44910621256

This seems 👀 related to my changes, though, so I'll try to find a test for it and then fix it, if possible.

paulo-ferraz-oliveira · 2025-06-27T11:41:00Z

I don't think I'll be able to write a proper test, not without some complexity, because > is a moving target, but I can try to fix it, still... for me, in the tests, it's picking master (OTP) and v1.19 (Elixir).

paulo-ferraz-oliveira · 2025-06-27T11:51:22Z

I think we'll have to open an exception for Elixir there:

maint, in Erlang, means https://erlangforums.com/t/clarify-the-role-of-the-maint-branch/4166/4?u=paulo-f-oliveira.

But I don't think there's a correspondence in Elixir's builds.txt, is there?

The same goes for maint-....

For master, though, I can try to pin it to master-otp-<latest>, is that the expectation?

paulo-ferraz-oliveira · 2025-06-27T12:18:34Z

There you go: https://github.com/erlef/setup-beam/actions/runs/15926064004/job/44923493706?pr=351#step:5:1

If the -rc. is not solved yet... I think that's a different issue still, and maybe we can start with a couple of tests we'd like to work toward?

wojtekmach · 2025-06-27T15:25:27Z

Yeah, totally up to you how you wanna proceed with this. I was just trying to be helpful pointing error scenarios that were not caught with tests.

But I don't think there's a correspondence in Elixir's builds.txt, is there?

Correct, there's no OTP maint counterpart in Elixir.

The same goes for maint-....

OTP maint-28 counterpart would be Elixir v1.18 branch and corresponding builds:

$ curl -fsS https://builds.hex.pm/builds/elixir/builds.txt | grep 'v1\.18[\ -]'
v1.18 71846797880c7649446a44eed89a4f1ccb00e8d3 2025-06-07T13:37:26Z ed1307db129f71b39ead8fe1c51e1dc2ed2977c8867c7523ebee4f0ca515b092
v1.18-otp-25 71846797880c7649446a44eed89a4f1ccb00e8d3 2025-06-07T13:37:26Z ed1307db129f71b39ead8fe1c51e1dc2ed2977c8867c7523ebee4f0ca515b092
v1.18-otp-26 71846797880c7649446a44eed89a4f1ccb00e8d3 2025-06-07T13:37:26Z e7a93fc017d739cf37faf0c6e0184e800e7bb1042e4a05ded401f97c9fc38cbc
v1.18-otp-27 71846797880c7649446a44eed89a4f1ccb00e8d3 2025-06-07T13:37:26Z 10e32d04626b6fd06751c6a419f07da589ff7c2da30428f4f822ff222261d138

For master, though, I can try to pin it to master-otp-, is that the expectation?

not sure if this is what you were asking but for:

elixir-version: "main"
otp-version: "master"

it is important to grab, at the time of writing, main-otp-28, indeed the latest, not main-otp-25 like today. At the moment OTP master resolves to OTP-29 and it is not guaranteed to handle (and most likely doesn't) byte code compiled against OTP 25. My understanding is OTP maintains compatibility for last 3 major versions only.

paulo-ferraz-oliveira · 2025-06-27T21:11:38Z

I was just trying to be helpful pointing error scenarios that were not caught with tests.

And they were helpful for sure, thank you.

OTP maint-28 counterpart would be Elixir v1.18 branch and corresponding builds:

Is this easy to have a rule for? Or is it an unlikely scenario? Because I'm not sure we want exceptions like hardcoded versions...

My understanding is OTP maintains compatibility for last 3 major versions only.

Correct, at least for the distribution protocol and support range.

What you're pointing out (as missing) is master / maint not pointing the correct version, right? Is there a rule we can apply here?

wojtekmach · 2025-06-27T21:24:05Z

OTP maint-28 counterpart would be Elixir v1.18 branch and corresponding builds:

Is this easy to have a rule for? Or is it an unlikely scenario? Because I'm not sure we want exceptions like hardcoded versions...

just to be clear, you were asking if there is a maint equivalent and there isn’t, and if there is maint-RELEASE equivalent and there is, vMAJOR.MINOR.

what do you mean by having a rule?

Are you asking what’s the rule elixir-version: main, otp-version: master should resolve the prebuilt elixir too? I think download otp master, get its version, 29, see if there is main-otp-29, there isn’t, try next in order, main-otp-28, bingo.

paulo-ferraz-oliveira · 2025-06-27T21:41:19Z

if there is maint-RELEASE equivalent and there is, vMAJOR.MINOR.

what do you mean by having a rule?

I meant "if somebody were to choose OTP maint-28 what Elixir version should the action choose, e.g., given a range"...

You wrote

OTP maint-28 counterpart would be Elixir v1.18 branch and corresponding builds:

But then there's 4 versions, so which one should the version auto pick... I'm thinking e.g., for > 0 (as a range). But if you think that in that case the choice should be done by the consumer then the action doesn't need to do anything different, I guess.

paulo-ferraz-oliveira · 2025-06-27T21:43:42Z

Are you asking what’s the rule elixir-version: main, otp-version: master should resolve the prebuilt elixir too? I think download otp master, get its version, 29, see if there is main-otp-29, there isn’t, try next in order, main-otp-28, bingo.

Per https://github.com/erlef/setup-beam/actions/runs/15926064004/job/44923493706?pr=351#step:5:8, I guess that's what'll happen when otp-29 is out.

paulo-ferraz-oliveira · 2025-06-27T21:46:03Z

I'm pushing a new test for OTP master / Elixir main to check the result...

paulo-ferraz-oliveira · 2025-06-27T21:49:13Z

It fails on OTP master / Elixir main because it actually picks version Elixir main which exists. I'm not sure what's the context of that one, but imagine it's the tip of the pre-release branch main. I'm gonna check how the versions get packed for choice.

wojtekmach · 2025-06-27T21:57:58Z

But then there's 4 versions

What are the 4 versions?

1.18.4
1.18.4-otp-27
1.18.4-otp-26
1.18.4-otp-25

those four?

paulo-ferraz-oliveira · 2025-06-27T21:59:30Z

But then there's 4 versions

What are the 4 versions?

1.18.4 1.18.4-otp-27 1.18.4-otp-26 1.18.4-otp-25

those four?

Correct, but in any case I think there's no follow-up here. The consumer should know what they're asking for, especially if they want a specific Elixir version.

paulo-ferraz-oliveira · 2025-06-27T22:04:38Z

It fails on OTP master / Elixir main because it actually picks version Elixir main which exists. I'm not sure what's the context of that one, but imagine it's the tip of the pre-release branch main. I'm gonna check how the versions get packed for choice.

Does it make sense to have an exception for this? Because we're not execution the OTP bin to fetch a version, from master, we just:

check if OTP master exists (in the version listing); it does, install it
check if Elixir main exists (in the version listing); it does, install it
...

rebar3 is saying something about SSL, most likely because our tests are installing a bunch of OTPs which makes for unpredictable behavior

paulo-ferraz-oliveira · 2025-06-28T03:00:03Z

I think I'm done for now, again. I'll re-summarise at the top.

Schultzer

LGTM, It’s great that we get rid of those regexes.

paulo-ferraz-oliveira · 2025-06-29T21:40:10Z

@wojtekmach, when you test this out (or just comment based on the content) I'll be ready to merge and release as patch.

wojtekmach · 2025-07-01T08:12:45Z

Looks good in my tests: https://github.com/wojtekmach/setup_beam_bug/actions/runs/15993638443, 👍

paulo-ferraz-oliveira · 2025-07-01T21:20:12Z

This was released in v1.20.2.

paulo-ferraz-oliveira requested a review from wojtekmach June 26, 2025 22:04