Improve visibility (+fix bugs) over version-type and opt-in versions #57
Conversation
| @@ -92,6 +92,10 @@ jobs: | |||
| otp-version: '24' | |||
| rebar3-version: '3.15' | |||
| os: 'ubuntu-20.04' | |||
| - elixir-version: 'v1.11.0' | |||
There was a problem hiding this comment.
Added because an issue was found live for this specific combo (and also because 'version-type': 'strict' was not being tested in the GitHub workflows).
| specifier (`1.11.0-rc.0`). Pre-release versions are opt-in, so `1.11.x` will | ||
| not match a pre-release. | ||
| For pre-release versions, such as `v1.11.0-rc.0`, use the full version | ||
| specifier (`v1.11.0-rc.0`) and set option `version-type` to `strict`. Pre-release versions are |
There was a problem hiding this comment.
version-type will not always be required, for rc, but it's best to recommend it because if used results are guaranteed to be better.
| @@ -159,6 +159,18 @@ jobs: | |||
|
|
|||
| The Elixir Problem Matchers in this repository are adapted from [here](https://github.com/fr1zle/vscode-elixir/blob/45eddb589acd7ac98e0c7305d1c2b24668ca709a/package.json#L70-L118). See [MATCHER_NOTICE](MATCHER_NOTICE.md) for license details. | |||
|
|
|||
| ## Action versioning | |||
There was a problem hiding this comment.
Let me know about this: this is my attempt at making sure consumers don't rely on potentially breaking versions (this schema is almost like the "ranges" we implement) 😄
| @@ -4788,7 +4789,7 @@ async function getElixirVersion(exSpec0, otpVersion) { | |||
| const elixirVersions = await getElixirVersions() | |||
| const semverVersions = Array.from(elixirVersions.keys()).sort() | |||
|
|
|||
| const exSpec = exSpec0.match(/^(.+)(-otp-.+)/) || exSpec0.match(/^(.+)/) | |||
| const exSpec = exSpec0.match(/^v?(.+)(-otp-.+)/) || exSpec0.match(/^v?(.+)/) | |||
There was a problem hiding this comment.
We remove the v from the input, to later add it back again (this way we allow v1.12 as well as 1.12).
| @@ -4896,7 +4899,7 @@ async function getElixirVersions() { | |||
| .split('\n') | |||
| .forEach((line) => { | |||
| const elixirMatch = | |||
| line.match(/^(.+)-otp-([^ ]+)/) || line.match(/^([^ ]+)/) | |||
| line.match(/^v?(.+)-otp-([^ ]+)/) || line.match(/^v?([^ ]+)/) | |||
There was a problem hiding this comment.
This is where we remove the v from the listing (this way we allow v1.12 as well as 1.12).
| @@ -4928,18 +4931,24 @@ async function getRebar3Versions() { | |||
| function getVersionFromSpec(spec, versions) { | |||
| let version = null | |||
|
|
|||
| if (core.getInput('version-type', { required: false }) === 'strict') { | |||
| if ( | |||
| spec.match(/rc/) || | |||
There was a problem hiding this comment.
Since we're not allowing rc below we try to fetch one from the listing, here. If it is an rc we consider the match to be strict.
| ) | ||
| } | ||
|
|
||
| return elixirVersionWithOTP | ||
| return `v${elixirVersionWithOTP}` |
There was a problem hiding this comment.
And this is where we add it back. Mind you (https://repo.hex.pm/builds/elixir/builds.txt) all versions start with a v except for master (I'm not sure we want an exception for master, so keeping it out, for the time being).
(and tweak README regarding action versioning)
| otp-version: '22.3.4.1' | ||
| os: 'ubuntu-20.04' | ||
| version-type: 'strict' | ||
| - elixir-version: '1.10.3' |
There was a problem hiding this comment.
Same as before, without 'strict'. This proves strict isn't always required in non-semver cases.
| @@ -4948,13 +4952,26 @@ function getVersionFromSpec(spec, versions) { | |||
| version = | |||
| versionsMap[semver.maxSatisfying(Object.keys(versionsMap), rangeForMax)] | |||
| } else { | |||
| version = versionsMap[spec] | |||
| version = versionsMap[maybeCoerced(spec)] | |||
There was a problem hiding this comment.
We were missing this. We added, say, 1.13.2 for 1.13.2.1 but then searched for 1.13.2.1, which wouldn't be found.
(and tweak README regarding action versioning)
This hopefully closes #56. I'm adding the info on that ticket to the tests, as I go.