2
2
3
3
A GitHub action for using the latest released Go version and your
4
4
projects minimal support Go version (from go.mod), and a build matrix
5
- of them and all versions in between.
5
+ of them, and all versions in between.
6
6
7
7
## Motive
8
8
9
9
Being consistent is hard.
10
10
11
- I used to hard code the Go versions my projects needed for test and
11
+ I used to hard- code the Go versions my projects needed for test and
12
12
builds in my GitHub Actions workflow files.
13
13
14
- Of course the result was that I used different versions in the
14
+ Of course, the result was that I used different versions in the
15
15
` go.mod ` file and my workflow files.
16
16
17
- Whenever a new version of Go was released I forgot to add the new
17
+ Whenever a new version of Go was released, I forgot to add the new
18
18
version to my build matrix and my projects weren't tested on the new
19
19
release(s).
20
20
21
- So I build this action.
21
+ So, I build this action.
22
22
23
23
The action reads the minimal supported Go version from your ` go.mod `
24
- file and exposes it as a variable to you workflow.
24
+ file and exposes it as a variable to your workflow.
25
25
26
26
It also pulls the list of release tags from
27
27
[ https://go.dev/dl/ ] ( https://go.dev/dl/ ) and exposes the latest
28
28
released Go version as a variable as well.
29
29
30
- From the list of released Go versions and the minimal version your
30
+ From the list of released Go versions and the minimal version, your
31
31
module supports we also build a "matrix" variable to be used as a
32
32
build matrix.
33
33
34
- While we are at it we also extract the module path from the ` go.mod `
35
- file even though it hasn't really anything to do with versions ;)
34
+ While we are at it, we also extract the module path from the ` go.mod `
35
+ file, even though it hasn't really anything to do with versions ;)
36
36
37
37
## Inputs
38
38
39
- If your ` go mod ` file is located in a non standard location you can
39
+ If your ` go mod ` file is located in a non- standard location, you can
40
40
specify the working directory where it is located:
41
41
42
42
``` yaml
43
43
working-directory :
44
- description : Working directory where you go.mod file is located
44
+ description : Working directory where your go.mod file is located
45
45
required : false
46
46
default : .
47
- unsupported :
48
- description : Include unsupported versions of Go
49
- required : false
50
- default : ' true'
51
47
unstable :
52
48
description : Include unstable versions of Go (beta, release candidates)
53
49
required : false
54
50
default : ' false'
51
+ unsupported :
52
+ description : Include unsupported versions of Go
53
+ required : false
54
+ default : ' true'
55
55
patch-level :
56
56
description : Include the patch levels on the versions (default is major.minor)
57
57
required : false
@@ -61,22 +61,22 @@ patch-level:
61
61
## Outputs
62
62
63
63
` ` ` yaml
64
- module :
65
- description : The Go module path (as specified by go.mod)
66
64
go-mod-version :
67
65
description : The Go version specified by go.mod
66
+ latest :
67
+ description : The latest Go version
68
68
minimal :
69
69
description : The minimal Go version
70
70
matrix :
71
- description : An (stringified) array of Go versions from the minimal supported version to the latest released version
72
- latest :
73
- description : The latest Go version
71
+ description : A (stringified) array of Go versions from the minimal supported version to the latest released version
72
+ module :
73
+ description : The Go module path (as specified by go.mod)
74
74
` ` `
75
75
76
76
## Examples
77
77
78
78
Let's say your ` go.mod` specifies Go 1.13 as the minimal supported
79
- version and you want your workflow to setup Go version 1.13 using the
79
+ version and you want your workflow to set up Go version 1.13 using the
80
80
[actions/setup-go](https://github.com/actions/setup-go) action :
81
81
82
82
` ` ` yaml
0 commit comments