Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow version-type: strict + otp-version: master for Elixir -based builds #144

Merged
merged 16 commits into from
Oct 19, 2022
Merged

Allow version-type: strict + otp-version: master for Elixir -based builds #144

merged 16 commits into from
Oct 19, 2022

Conversation

paulo-ferraz-oliveira
Copy link
Collaborator

@paulo-ferraz-oliveira paulo-ferraz-oliveira commented Oct 2, 2022

(edit: though the title is somewhat restrictive I believe this fix should work for Gleam -based builds in the same way)

@ericmj found that we can't use combo

  otp-version: master
  elixir-version: 1.14.0-otp-master

but this is unintentional, as we should, with version-type: strict. This pull request aims to fix that.

@paulo-ferraz-oliveira paulo-ferraz-oliveira changed the title Check tests failing for something that should pass Allow version-type: strict + otp-version: master for Elixir -based builds Oct 2, 2022
@paulo-ferraz-oliveira
Copy link
Collaborator Author

We add a workflow -based test and a unit test for this change. Since I'm doing only additions to the code, I'm pretty confident there's no regressions (believing that all previous tests were already very comprehensive).

Actions' window shows everything as Ok but then internals not

Error when evaluating 'runs-on' for job 'integration_test'. .github/workflows/ubuntu.yml (Line: 19, Col: 14): Unexpected type of value '', expected type: OneOf.

Strange one, this one!
@paulo-ferraz-oliveira
Copy link
Collaborator Author

Ah, wait, spoke too soon. This appears to have some kind of influence of previously working tests. Now I just need to make sure the tests were meaningful and correct as per this change.

@paulo-ferraz-oliveira
Copy link
Collaborator Author

I guess strict still tries to do some guess work in unexpected cases. I'll fix that.

We do this for OTP-, but not for maint-
as the former is hopefully more common
than the latter
@paulo-ferraz-oliveira
Copy link
Collaborator Author

paulo-ferraz-oliveira commented Oct 2, 2022

@ericmj, what should happen if a developer chooses Elixir master but OTP 25? As opposed to Elixir master and OTP 24? In the latter we know how to choose master-otp-24, but how should we know to only choose master if OTP is 25 (i.e. without reading the whole builds.txt and deducing that)?

(edit: from #134 (comment) I'd already asked "Should we open an exception, in the code, for master? I see that -otp-25 only shows up some times, so not sure what the rule is, here." for a lack of rule, but I'm still wondering how we could improve this).

(edit 2: also, I'm not sure if Elixir master is OTP 25 or OTP master, in which case master/master, in the input, could be reduced to master alone).

(edit 3: we could also implement OTP version as latest which would imply master but no suffix to the Elixir version)

(edit 4: error is specifically here https://github.com/erlef/setup-beam/actions/runs/3170320256/jobs/5162830251#step:3:16; we try to fetch 25 and end up with maint-25, but even if we were to end up with OTP-25 there'd be no easy-to-find corresponding Elixir version - i.e. how do we specify 1. Elixir master with OTP master and 2. Elixir master and OTP 25?)

Semantically they're similar, but with `latest` we know:
1. to fetch Elixir's no-otp-... version
2. to fetch Erlang's master

whereas with 25 (latest at this moment) we'd
try to fetch elixirvsn-otp-25 which could fail with
Elixir master and version-type strict
Still not 100% convinced that `latest` should be separate from `master`
but I want to know how tests run, in this case in particular
We introduce the concept of version v. branch (as per @ericmj)
and we use that to find the most appropriate Erlang/Elixir combo.
@@ -21,6 +21,13 @@ jobs:
fail-fast: false
matrix:
combo:
- otp-version: 'master'
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added as part of the "was failing, but shouldn't!" testbed.

@@ -113,12 +120,13 @@ jobs:
- elixir-version: 'master'
otp-version: '23.1'
os: 'ubuntu-20.04'
- elixir-version: 'master'
- elixir-version: 'main'
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was actually a fix. Since OTP 25, Elixir no longer has master, but main.

otp-version: '25'
os: 'ubuntu-20.04'
version-type: 'strict'
- gleam-version: 'nightly'
otp-version: '24'
os: 'ubuntu-latest'
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this should've been broken, but can't understand how we didn't see it before. In any case, on the README, the Ubuntu build is broken and there were recently issues with running actions on GitHub actions like so, which was hiding bugs.

@@ -205,9 +213,9 @@ async function testElixirVersions() {
simulateInput('version-type', 'loose')

simulateInput('version-type', 'strict')
spec = 'master'
spec = 'main'
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explained above, though probably only meaningful for OTP 25+

@@ -7189,8 +7189,8 @@ async function main() {
const rebar3Spec = core.getInput('rebar3-version', { required: false })

if (otpSpec !== 'false') {
const otpVersion = await installOTP(otpSpec, osVersion)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We install Elixir based on the direct OTP input, and not the output of this function (easier to reason about)...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice one!

otpSpec[2],
Array.from(otpVersions.keys()).sort(),
)
let otpSpec = otpSpec0 // might be a branch (?)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Greatly simplified. We drop OTP-, maint- and whatnot to favour "branch over version," as suggested by @ericmj.

@@ -7324,60 +7318,46 @@ async function getOTPVersion(otpSpec0, osVersion) {
return otpVersions.get(otpVersion) // from the reference, for download
}

async function getElixirVersion(exSpec0, otpVersion) {
async function getElixirVersion(exSpec0, otpVersion0) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also greatly simplified as per previous explanation.

@@ -7438,7 +7420,6 @@ async function getOTPVersions(osVersion) {
})
})
}

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unintended...

@paulo-ferraz-oliveira
Copy link
Collaborator Author

@ericmj, did you get around to testing this?

@paulo-ferraz-oliveira
Copy link
Collaborator Author

@starbelly, I'm recruiting your help to validate these changes, as @ericmj might not be available at this moment. They are not only pertinent to the initial problem issued by @ericmj, but also generally to improve the code base. I can walk you through the changes if there's something you don't understand or need further detail on.

@starbelly
Copy link
Member

The changes look reasonable, let me give this a whirl in a test project tomorrow.

"should not contain '-otp-...'",
)
const exSpec = exSpec0.replace(/-otp-.*$/, '')
const elixirVersionFromSpec = getVersionFromSpec(exSpec, semverVersions, true)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only thing I don't like, the boolean blindness, but it's javascript so 🤷 😁 The only thing I could thing to do improve this is to pass around an object, I would not block on it though.

Copy link
Member

@starbelly starbelly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@paulo-ferraz-oliveira This looks solid to me. Tested and all. Since it's not a small change, we may want to hold off on force pushing it the v1 tag and maybe ask some other to try it for a bit. I'll certainly give it a solid whirl at work for a while. What do you think?

Regardless, approved 🎯

Copy link
Collaborator

@ericmj ericmj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@paulo-ferraz-oliveira
Copy link
Collaborator Author

@starbelly, I can push the minor and patch only, but will need a comment from you, or anybody else, in a few days, to force-push v1.

@paulo-ferraz-oliveira
Copy link
Collaborator Author

v1.14 and v1.14.0 pushed. I'll create the release now. @starbelly, do let us know soonish, so we can force push v1. Thanks.

@starbelly
Copy link
Member

@paulo-ferraz-oliveira Ship it!! 🥳

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants