Support latest version tag

[Schultzer]

Is your feature request related to a problem?

There is no way to specify the latest version, such as ubuntu-latest.

Describe the feature you'd like

Being able to retrieve the latest version of Elixir and Erlang OTP:

elixir:  latest
otp: latest

Describe alternatives you've considered

Currently using main and maint, but those branches are in constant development, and I want to be able to test on the latest release.

[paulo-ferraz-oliveira]

👋, @Schultzer.

What would be considered latest for the current versions? The action doesn't keep track of the major number, so I'm not sure how we'd be able to track that. You mean, for example, ordering the versions we get and latest would be the one with the highest major.minor.patch?

And would we consider release candidates?

In the meantime, I imagine using

elixir-version: 1
erlang-version: 27

is as close as it gets. (?)

[Schultzer]

I’m currently building an integration test for @elixir-cldr, and I think if the tags are sorted by name, we would be able to get the latest major.minor.patch release regardless of when it was released.

I have not tested this personally, but I would be surprised if it’s not possible even with JS sharp edges for sorting.

I’m not interested in specifying anything other than the latest since that would mean that I’ll have to update the workflow every time there is a new release, which defeats the purpose of an early warning system.

[paulo-ferraz-oliveira]

@Schultzer, what would be considered latest for the current versions? And would we consider release candidates?

Edit: you can fetch latest (as per GitHub's definition) from https://api.github.com/repos/erlang/otp/releases/latest and https://api.github.com/repos/elixir-lang/elixir/releases/latest (JSON key tag_name in both case)

[Schultzer]

@Schultzer, what would be considered latest for the current versions? And would we consider release candidates?

Edit: you can fetch latest (as per GitHub's definition) from https://api.github.com/repos/erlang/otp/releases/latest and https://api.github.com/repos/elixir-lang/elixir/releases/latest (JSON key tag_name in both case)

I apologize for not being clear; RC is welcome but unnecessary. I mainly just wanted the highest major.minor.patch.

I'll give the tag_name a try; if it works, then documenting might be appropriate.

Edit: @paulo-ferraz-oliveira I looked at the source code, and it does not look like I could define the tag_name in the action. Can you guide me on how I could fetch the latest with the action?

[paulo-ferraz-oliveira]

it does not look like I could define the tag_name in the action

I mentioned this as such:

1. you could use the GitHub API to fetch the latest
2. you could then pass that to the action

We can, if time allows, implement latest, but PRs are also welcome; not implementing the rc, to start, seems compatible with what we do already for non-strict versions.

[paulo-ferraz-oliveira]

I was thinking about something like

---
"on": push
jobs:
  example:
    runs-on: ubuntu-22.04
    steps:
      - env:
          GH_TOKEN: ${{ github.token }}
        run: |
          echo "otp-version=$(gh release view --repo erlang/otp --json tagName --jq .tagName)" >> "${GITHUB_OUTPUT}"
          echo "elixir-version=$(gh release view --repo elixir-lang/elixir --json tagName --jq .tagName)" >> "${GITHUB_OUTPUT}"
        id: latest-versions
      - uses: erlef/setup-beam@v1
        with:
          otp-version: ${{ steps.latest-versions.outputs.otp-version }}
          elixir-version: ${{ steps.latest-versions.outputs.elixir-version }}

A recent run chose latest as:

• Erlang/OTP 26.2.5
• Elixir 1.16.2

Of course, the semantics (and choice) of latest depend on the maintainers of the repo. not GitHub...

Edit: this would be something the action would eventually do (instead of choosing the latest from the build lists it downloads), since it's probably not good to have semantics on "latest" in the action and not the origin repo.

[Schultzer]

I was thinking about something like

---
"on": push
jobs:
  example:
    runs-on: ubuntu-22.04
    steps:
      - env:
          GH_TOKEN: ${{ github.token }}
        run: |
          echo "otp-version=$(gh release view --repo erlang/otp --json tagName --jq .tagName)" >> "${GITHUB_OUTPUT}"
          echo "elixir-version=$(gh release view --repo elixir-lang/elixir --json tagName --jq .tagName)" >> "${GITHUB_OUTPUT}"
        id: latest-versions
      - uses: erlef/setup-beam@v1
        with:
          otp-version: ${{ steps.latest-versions.outputs.otp-version }}
          elixir-version: ${{ steps.latest-versions.outputs.elixir-version }}

A recent run chose latest as:

• Erlang/OTP 26.2.5
• Elixir 1.16.2

Of course, the semantics (and choice) of latest depend on the maintainers of the repo. not GitHub...

Edit: this would be something the action would eventually do (instead of choosing the latest from the build lists it downloads), since it's probably not good to have semantics on "latest" in the action and not the origin repo.

That's amazing, I ended up putting something together here: #267