* Update some dependencies' versions (also, get rid of husky) * Introduce branch dependency execution We want the most important things to fail first and prevent the other ones from executing e.g. if your dist/ is not updated, there's no point seeing the tests fail * Rid ourselves of bloat * Introduce expectations for upcoming version * Tweak whitespace * Tweak our calls to getVersionFromSpec (increase code consistency) * Remove non-used variable * Start coercing on input, stop sorting/maybe prepending 'v' on input We'll deal with all this in a centralized place to make it easier to reason on the code * Revamp our getVersionFromSpec 1. stop accepting maybePrependWithV0, since this is only used in specialized cases 2. sort versions internally (don't expect it to come sorted) 3. compare rc/strict and .includes in a single go (don't separate these) 4. don't expect already coerced version arrays, coerce them when required (the maybeCoerced version had changed already, which means we're smarter at putting stuff inside the version array) 5. raise an exception if a semver-invalid version is not flagged as strict * Reduce our expectations, but still be appropriate to our mission * Update our tests for our new expectations (start the TDD bit) * Execute npm run build-dist and keep results * Increase inter-job dependency * Don't expect markdownlint to be installed remotely * Revert "Increase inter-job dependency" This reverts commit 500b0fe7e9eec1c4f258b4d16b40719ee1d0a1ad. * Revert "Introduce branch dependency execution" This reverts commit fbe1317a800d7722f4e8b668c073218263d0ab17. * Have all the CI workflows run under the same conditions * Fix as per CI results * Re-establish the possibility to match versions like 22.3.4.2.1.0 We cheat on the semver matching: 1. we keep an ordered list of versions that respect e.g. 22.3.4 2. if we match 22.3.4 when fetching a version, we get the last value from the list of versions that respect it, e.g. 22.3.4.2.1.0 (since this is ordered, it should work as previously expected) This increases code complexity for getVersionFromSpec, but hopefully not by much... We also remove throw-based test cases (non-versions will fail later, with null), and add some tests to prove our need code. * Trim out linting practices But still keep them useful
setup-beam

This action sets up an Erlang/OTP environment for use in a GitHub Actions workflow by:
- installing Erlang/OTP
- optionally, installing Elixir
- optionally, installing Gleam
- optionally, installing
rebar3 - optionally, installing
hex - optionally, opting for strict or loose version matching
- optionally, having problem matchers show warnings and errors on pull requests
- optionally, using a version file (as explained in "Version file", below), to identify versions
Note: currently, this action only supports Actions' ubuntu- and windows- runtimes.
Usage
See action.yml for the action's specification.
Note: the Erlang/OTP release version specification is relatively
complex.
For best results, we recommend specifying exact
versions, and setting option version-type to strict.
However, values like 22.x, or even >22, are also accepted, and we attempt to resolve them
according to semantic versioning rules. This implicitly means version-type is loose,
which is also the default value for this option.
Additionally, it is recommended that one specifies versions
using YAML strings, as these examples do, so that numbers like 23.0 don't
end up being parsed as 23, which is not equivalent.
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
opt-in, so 1.11.x will not match a pre-release.
Compatibility between Operating System and Erlang/OTP
This list presents the known working version combos between the target operating system and Erlang/OTP.
| Operating system | Erlang/OTP | Status |
|---|---|---|
| ubuntu-18.04 | 17 - 25 | ✅ |
| ubuntu-20.04 | 20 - 25 | ✅ |
| ubuntu-22.04 | 24.2 - 25 | ✅ |
| windows-2019 | 21* - 25 | ✅ |
| windows-2022 | 21* - 25 | ✅ |
Note *: prior to 23, Windows builds are only available for minor versions, e.g. 21.0, 21.3, 22.0, etc.
Self-hosted runners
Self-hosted runners need to set env. variable ImageOS to one of the following, since the action
uses that to download assets:
| ImageOS | Operating system |
|---|---|
| ubuntu18 | ubuntu-18.04 |
| ubuntu20 | ubuntu-20.04 |
| ubuntu22 | ubuntu-22.04 |
| win19 | windows-2019 |
| win22 | windows-2022 |
as per the following example:
...
jobs:
test:
runs-on: self-hosted
env:
ImageOS: ubuntu20 # equivalent to runs-on ubuntu-20.04
steps:
- uses: actions/checkout@v3
- uses: erlef/setup-beam@v1
...
Version file
A version file is specified via input version-file (e.g..tool-versions). This
allows not having to use YML input for versions, though the action does check (and
will exit with error) if both inputs are set.
Note: if you're using a version file, option version-type is checked to be strict,
and will make the action exit with error otherwise.
The following version file formats are supported:
.tool-versions, as specified by asdf: Configuration
Supported version elements are the same as the ones defined for the YML portion of the action, with the following correspondence.
.tool-versions format
| YML | .tool-versions |
|---|---|
otp-version |
erlang |
elixir-version |
elixir |
gleam-version |
gleam |
rebar3-version |
rebar |
Example (Erlang/OTP + Elixir, on Ubuntu)
# create this in .github/workflows/ci.yml
on: push
jobs:
test:
runs-on: ubuntu-20.04
name: OTP ${{matrix.otp}} / Elixir ${{matrix.elixir}}
strategy:
matrix:
otp: ['20.3', '21.3', '22.2']
elixir: ['1.8.2', '1.9.4']
steps:
- uses: actions/checkout@v3
- uses: erlef/setup-beam@v1
with:
otp-version: ${{matrix.otp}}
elixir-version: ${{matrix.elixir}}
- run: mix deps.get
- run: mix test
Example (Erlang/OTP + rebar3, on Ubuntu)
# create this in .github/workflows/ci.yml
on: push
jobs:
test:
runs-on: ubuntu-20.04
name: Erlang/OTP ${{matrix.otp}} / rebar3 ${{matrix.rebar3}}
strategy:
matrix:
otp: ['20.3', '21.3', '22.2']
rebar3: ['3.14.1', '3.14.3']
steps:
- uses: actions/checkout@v3
- uses: erlef/setup-beam@v1
with:
otp-version: ${{matrix.otp}}
rebar3-version: ${{matrix.rebar3}}
- run: rebar3 ct
Example (Erlang/OTP + rebar3, on Windows)
# create this in .github/workflows/ci.yml
on: push
jobs:
test:
runs-on: windows-2022
steps:
- uses: actions/checkout@v3
- uses: erlef/setup-beam@v1
with:
otp-version: '24'
rebar3-version: '3.16.1'
- run: rebar3 ct
Example (Gleam on Ubuntu)
# create this in .github/workflows/ci.yml
on: push
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: erlef/setup-beam@v1
with:
otp-version: '24'
gleam-version: '0.23.0-rc1'
- run: gleam test
Example (Gleam on Ubuntu without OTP)
# create this in .github/workflows/ci.yml
on: push
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: erlef/setup-beam@v1
with:
otp-version: false
gleam-version: '0.23.0-rc1'
- run: gleam check
Note: the otp-version: false input is only applicable when installing Gleam.
Alternative hex.pm mirrors
It is possible to use alternative hex.pm mirror(s), in their declared order, with
option hexpm-mirrors. By default, the action will use builds.hex.pm.
To use other alternative mirrors, add one per line, as shown below.
# create this in .github/workflows/ci.yml
on: push
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: erlef/setup-beam@v1
with:
otp-version: '25'
# Use `cdn.jsdelivr.net/hex` as an alternative to `builds.hex.pm`
hexpm-mirrors: https://cdn.jsdelivr.net/hex
Alternatively, you may try cdn.jsdelivr.net/hex if builds.hex.pm fails:
# create this in .github/workflows/ci.yml
on: push
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: erlef/setup-beam@v1
with:
otp-version: '25'
hexpm-mirrors: |
https://builds.hex.pm
https://cdn.jsdelivr.net/hex
Environment variables
Base installation folders (useful for e.g. fetching headers for NIFs) are available in the following environment variables:
INSTALL_DIR_FOR_OTP: base folder for Erlang/OTPINSTALL_DIR_FOR_ELIXIR: base folder for ElixirINSTALL_DIR_FOR_GLEAM: base folder for GleamINSTALL_DIR_FOR_REBAR3: base folder forrebar3
Elixir Problem Matchers
The Elixir Problem Matchers in this repository are adapted from here. See MATCHER_NOTICE for license details.
Action versioning
setup-beam has three version paths, described below, for example version 1.8.0:
@v1: the latest in the1.y.zseries (this tag is movable),@v1.8: the latest in the1.8.zseries (this tag is movable),@v1.8.0: release1.8.0(this tag is not movable).
We make a real effort to not introduce incompatibilities without changing the major
version number. To be extra safe against changes causing issues in your CI you should specify
an exact version with @vx.y.z.
License
The scripts and documentation in this project are released under the MIT license.
Contributing
Check out this doc.
Current Status
This action is in active development.