neiam /action-setup-beam

action-setup-beam

public · Issues · Pulls · Labels · Forks · Compare · Actions queued

Tweak `markdownlint` rules and README versioning (#286)

54e90d4 · Paulo F. Oliveira · 2024-06-16 02:13

5 files +70 -42

Files changed

added .markdownlint.yml

+4 −0

@@ -0,0 +1,4 @@

	1	+---
	2	+default: true
	3	+MD013:
	4	+ line_length: 100

modified CODE_OF_CONDUCT.md

+0 −1

@@ -1,4 +1,3 @@

1		−<!-- markdownlint-disable MD013 -->
2	1	# Contributor Covenant Code of Conduct
3	2
4	3	## Our Pledge

modified CONTRIBUTING.md

+11 −6

@@ -1,15 +1,18 @@

1		−<!-- markdownlint-disable MD013 -->
2	1	# Contributing
3	2
4	3	[fork]: https://github.com/erlef/setup-beam/fork
5	4	[pr]: https://github.com/erlef/setup-beam/compare
6	5	[code-of-conduct]: https://github.com/erlef/setup-beam/blob/main/CODE_OF_CONDUCT.md
7	6
8		−Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
	7	+Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for
	8	+keeping it great.
9	9
10		−Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](LICENSE.md).
	10	+Contributions to this project are
	11	+[released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license)
	12	+to the public under the [project's open source license](LICENSE.md).
11	13
12		−Please note that this project is released with a [Contributor Code of Conduct][code-of-conduct]. By participating in this project you agree to abide by its terms.
	14	+Please note that this project is released with a [Contributor Code of Conduct][code-of-conduct]. By
	15	+participating in this project you agree to abide by its terms.
13	16
14	17	## Submitting a pull request
15	18

@@ -23,13 +26,15 @@ Please note that this project is released with a [Contributor Code of Conduct][c

23	26	Here are a few things you can do that will increase the likelihood of your pull request being accepted:
24	27
25	28	- Write tests.
26		−- Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
	29	+- Keep your change as focused as possible. If there are multiple changes you would like to make that
	30	+are not dependent upon each other, consider submitting them as separate pull requests.
27	31	- Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
28	32	- Execute `npm run build-dist` and fix any issues arising from that
29	33
30	34	## Running tests
31	35
32		−When running tests locally, a valid classic GitHub token with the `repo` scope is required for tests to pass.
	36	+When running tests locally, a valid classic GitHub token with the `repo` scope is required for tests
	37	+to pass.
33	38
34	39	- Export the token in the current shell: `export GITHUB_TOKEN=<contents>`
35	40	- Run tests `npm test`

modified LICENSE.md

+0 −1

@@ -1,4 +1,3 @@

1		−<!-- markdownlint-disable MD013 -->
2	1	# The MIT License (MIT)
3	2
4	3	Copyright (c) 2019 GitHub, Inc. and contributors

modified README.md

+55 −34

@@ -1,5 +1,4 @@

1		−<!-- markdownlint-disable MD013 -->
2		−# setup-beam [![GitHub Actions][action-img]][action] [![GitHub Actions][ubuntu-img]][ubuntu] [![GitHub Actions][windows-img]][windows]
	1	+# setup-beam [![Action][action-img]][action] [![Ubuntu][ubuntu-img]][ubuntu] [![Windows][windows-img]][windows]
3	2
4	3	[action]: https://github.com/erlef/setup-beam/actions/workflows/action.yml
5	4	[action-img]: https://github.com/erlef/setup-beam/actions/workflows/action.yml/badge.svg

@@ -28,23 +27,44 @@ workflow by:

28	27
29	28	See [action.yml](action.yml) for the action's specification.
30	29
31		−Note: the Erlang/OTP release version specification is [relatively
32		−complex](http://erlang.org/doc/system_principles/versions.html#version-scheme).
33		−For best results, we recommend specifying exact
	30	+### Input versioning
	31	+
	32	+Input (tools') versions are controlled via `with:` (check the examples below).
	33	+
	34	+#### Strict versions
	35	+
	36	+The Erlang/OTP release version specification, for example, is [relatively
	37	+complex](http://erlang.org/doc/system_principles/versions.html#version-scheme), so,
	38	+for best results, we recommend specifying exact
34	39	versions, and setting option `version-type` to `strict`.
	40	+
	41	+#### Version ranges
	42	+
35	43	However, values like `22.x`, or even `>22`, are also accepted, and we attempt to resolve them
36	44	according to semantic versioning rules. This implicitly means `version-type` is `loose`,
37	45	which is also the default value for this option.
38	46
	47	+#### Specify versions as strings, not numbers
	48	+
39	49	Additionally, it is recommended that one specifies versions
40	50	using YAML strings, as these examples do, so that numbers like `23.0` don't
41	51	end up being parsed as `23`, which is not equivalent.
42	52
	53	+#### Pre-release versions
	54	+
43	55	For pre-release versions, such as `v1.11.0-rc.0`, use the full version
44	56	specifier (`v1.11.0-rc.0`) and set option `version-type` to `strict`. Pre-release versions are
45	57	opt-in, so `1.11.x` will not match a pre-release.
46	58
47		−Use `latest` for the latest version; the latest version is calculated based on all the retrieved versions. Please take a look at the test cases for examples.
	59	+#### "Latest" versions
	60	+
	61	+Set a tool's version to `latest` to retrieve the latest version of a given tool.
	62	+The latest version is (locally) calculated by the action based on the (retrieved) versions
	63	+it knows (note: it is not the same as [GitHub considers it](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository)
	64	+and some repositories might propose).
	65	+
	66	+If in doubt do a test run and compare the obtained release with the one you were expecting to
	67	+be the latest.
48	68
49	69	### Compatibility between Operating System and Erlang/OTP
50	70

@@ -53,28 +73,29 @@ and Erlang/OTP.

53	73
54	74	\| Operating system \| Erlang/OTP \| Status
55	75	\|- \|- \|-
56		−\| ubuntu-18.04 \| 17.0 - 25.3 \| ✅
57		−\| ubuntu-20.04 \| 20.0 - 27 \| ✅
58		−\| ubuntu-22.04 \| 24.2 - 27 \| ✅
59		−\| ubuntu-24.04 \| 24.3 - 27 \| ✅
60		−\| windows-2019 \| 21* - 25 \| ✅
61		−\| windows-2022 \| 21* - 27 \| ✅
	76	+\| `ubuntu-18.04` \| 17.0 - 25.3 \| ✅
	77	+\| `ubuntu-20.04` \| 20.0 - 27 \| ✅
	78	+\| `ubuntu-22.04` \| 24.2 - 27 \| ✅
	79	+\| `ubuntu-24.04` \| 24.3 - 27 \| ✅
	80	+\| `windows-2019` \| 21* - 25 \| ✅
	81	+\| `windows-2022` \| 21* - 27 \| ✅
62	82
63		−Note *: prior to 23, Windows builds are only available for minor versions, e.g. 21.0, 21.3, 22.0, etc.
	83	+Note \*: prior to 23, Windows builds are only available for minor versions, e.g. 21.0, 21.3,
	84	+22.0, etc.
64	85
65	86	### Self-hosted runners
66	87
67	88	Self-hosted runners need to set env. variable `ImageOS` to one of the following, since the action
68	89	uses that to download assets:
69	90
70		−\| ImageOS \| Operating system
71		−\|- \|-
72		−\| ubuntu18 \| ubuntu-18.04
73		−\| ubuntu20 \| ubuntu-20.04
74		−\| ubuntu22 \| ubuntu-22.04
75		−\| ubuntu24 \| ubuntu-24.04
76		−\| win19 \| windows-2019
77		−\| win22 \| windows-2022
	91	+\| ImageOS \| Operating system
	92	+\|- \|-
	93	+\| `ubuntu18` \| `ubuntu-18.04`
	94	+\| `ubuntu20` \| `ubuntu-20.04`
	95	+\| `ubuntu22` \| `ubuntu-22.04`
	96	+\| `ubuntu24` \| `ubuntu-24.04`
	97	+\| `win19` \| `windows-2019`
	98	+\| `win22` \| `windows-2022`
78	99
79	100	as per the following example:
80	101

@@ -96,13 +117,13 @@ jobs:

96	117
97	118	The action provides the following outputs:
98	119
99		−\| Output \| Content
100		−\|- \|-
101		−\| otp-version \| The Erlang version, e.g. `OTP-26.0`
102		−\| elixir-version \| The Elixir version, e.g. `v1.14-otp-26`
103		−\| gleam-version \| The Gleam version, e.g. `v0.23.0`
104		−\| rebar3-version \| The `rebar3` version, e.g. `3.18.0`
105		−\| setup-beam-version \| The commit unique id of the executed action version, e.g. `a34c98f`
	120	+\| Output \| Content
	121	+\|- \|-
	122	+\| `otp-version` \| The Erlang version, e.g. `OTP-26.0`
	123	+\| `elixir-version` \| The Elixir version, e.g. `v1.14-otp-26`
	124	+\| `gleam-version` \| The Gleam version, e.g. `v0.23.0`
	125	+\| `rebar3-version` \| The `rebar3` version, e.g. `3.18.0`
	126	+\| `setup-beam-version` \| The commit unique id of the executed action version, e.g. `a34c98f`
106	127
107	128	accessible as `${{steps.<setup-beam-step-id>.outputs.<Output>}}`,
108	129	e.g. `${{steps.setup-beam.outputs.erlang-version}}`

@@ -125,12 +146,12 @@ with the following correspondence.

125	146
126	147	#### `.tool-versions` format
127	148
128		−\| YML \| `.tool-versions` \|
129		−\|- \|- \|
130		−\| `otp-version` \| `erlang` \|
131		−\| `elixir-version` \| `elixir` \|
132		−\| `gleam-version` \| `gleam` \|
133		−\| `rebar3-version` \| `rebar` \|
	149	+\| YML \| `.tool-versions`
	150	+\|- \|-
	151	+\| `otp-version` \| `erlang`
	152	+\| `elixir-version` \| `elixir`
	153	+\| `gleam-version` \| `gleam`
	154	+\| `rebar3-version` \| `rebar`
134	155
135	156	### Example (Erlang/OTP + Elixir, on Ubuntu)
136	157

Parents: 8fd1f5c