* Node 24 upgrade
Doing an upgrade for node 24, node 24 is stricter with types so need to add a type for achitecture
* format
* package updates
* fix for check failures
* upgrade @types/node
* update package.json version
* check failure fix
* package-lock.json update
* update node24
* npm run format
* npm run format
* node update from the workflows
* Upgrade `actions/checkout` to v5 and `actions/setup-go` to v6 in README.md
---------
Co-authored-by: Aparna Jyothi <aparnajyothi-y@github.com>
Co-authored-by: Priya Gupta <147705955+priyagupta108@users.noreply.github.com>
* Configure environment to avoid toolchain installs
Force `go` to always use the local toolchain (i.e. the one the one that
shipped with the go command being run) via setting the `GOTOOLCHAIN`
environment variable to `local`[1]:
> When GOTOOLCHAIN is set to local, the go command always runs the
bundled Go toolchain.
This is how things are setup in the official Docker images (e.g.[2], see
also the discussion around that change[3]). The motivation behind this
is to:
* Reduce duplicate work: if the `toolchain` version in `go.mod` was
greated than the `go` version, the version from the `go` directive
would be installed, then Go would detect the `toolchain` version and
additionally install that
* Avoid Unexpected behaviour: if you specify this action runs with some Go
version (e.g. `1.21.0`) but your go.mod contains a `toolchain` or `go`
directive for a newer version (e.g. `1.22.0`) then, without any other
configuration/environment setup, any go commands will be run using go
`1.22.0`
This will be a **breaking change** for some workflows. Given a `go.mod`
like:
module proj
go 1.22.0
Then running any `go` command, e.g. `go mod tidy`, in an environment
where only go versions before `1.22.0` were installed would previously
trigger a toolchain download of Go `1.22.0` and that version being used
to execute the command. With this change the above would error out with
something like:
> go: go.mod requires go >= 1.22.0 (running go 1.21.7;
GOTOOLCHAIN=local)
[1] https://go.dev/doc/toolchain#select
[2] dae3405a32/Dockerfile-linux.template (L163)
[3] https://github.com/docker-library/golang/issues/472
* Prefer installing version from `toolchain` directive
Prefer this over the version from the `go` directive. Per the docs[1]
> The toolchain line declares a suggested toolchain to use with the
module or workspace
It seems reasonable to use this, since running this action in a
directory containing a `go.mod` (or `go.work`) suggests the user is
wishing to work _with the module or workspace_.
Link: https://go.dev/doc/toolchain#config [1]
Issue: https://github.com/actions/setup-go/issues/457
* squash! Configure environment to avoid toolchain installs
Only modify env if `GOTOOLCHAIN` is not set
* squash! Prefer installing version from `toolchain` directive
Avoid installing from `toolchain` if `GOTOOLCHAIN` is `local`, also
better regex for matching toolchain directive
The vulnerability:
$ npm audit --audit-level=high
# npm audit report
form-data >=4.0.0 <4.0.4 || <2.5.4
Severity: critical
form-data uses unsafe random function in form-data for choosing boundary - https://github.com/advisories/GHSA-fjxv-7rqg-78g4
form-data uses unsafe random function in form-data for choosing boundary - https://github.com/advisories/GHSA-fjxv-7rqg-78g4
fix available via `npm audit fix`
node_modules/@azure/core-http/node_modules/form-data
node_modules/@types/node-fetch/node_modules/form-data
node_modules/form-data
1 critical severity vulnerability
To address all issues, run:
npm audit fix
This change is the result of from running `npm audit fix` and then
using[1] to update licenses via `licensed cache`.
It doesn't look like `dependabot` previously raised any PRs for this
dependency, so this bumps it from `4.0.0` to `4.0.4`, see the
changelog[2] for details.
Link: https://github.com/licensee/licensed [1]
Link: https://github.com/form-data/form-data/blob/v4.0.4/CHANGELOG.md [2]
* feat: fallback to "raw" endpoint for manifest when rate limit is reached
* add information about raw access to the README
* prettier
* update cross-spawn to 7.0.6 to fix vulnerability
* Update workflows and bump dependencies
* Add test for Go 1.22 and 1.23
* Update Go versions in local-cache setup and include macos-latest with ARM64 architecture
This workflow file publishes new action releases to the immutable action package of the same name as this repo.
This is part of the Immutable Actions project which is not yet fully released to the public. First party actions like this one are part of our initial testing of this feature.
* Fix emoji rendering
* Fix quoting
* Remove the description of the old go.mod specification
* Remove the single quotes from `go-version-file`
* Fix README
* Add description about patch versions to README
* Revert "Remove the single quotes from `go-version-file`"
This reverts commit ca4321abee.
<!--- Please direct any generic questions related to actions to our support community forum at https://github.community/c/code-to-cloud/github-actions/41 --->
<!--- Please direct any generic questions related to actions to our support community forum at https://github.com/orgs/community/discussions/categories/actions --->
<!--- Before opening up a new bug report, please make sure to check for similar existing issues -->
<!--- Before opening up a new bug report, please make sure to check for similar existing issues -->
<!--- Please direct any generic questions related to actions to our support community forum at https://github.community/c/code-to-cloud/github-actions/41 --->
<!--- Please direct any generic questions related to actions to our support community forum at https://github.com/orgs/community/discussions/categories/actions --->
<!--- Before opening up a new feature request, please make sure to check for similar existing issues and pull requests -->
<!--- Before opening up a new feature request, please make sure to check for similar existing issues and pull requests -->
@@ -8,26 +8,21 @@ This action sets up a go environment for use in actions by:
- Optionally downloading and caching a version of Go by version and adding to `PATH`.
- Optionally downloading and caching a version of Go by version and adding to `PATH`.
- Registering problem matchers for error output.
- Registering problem matchers for error output.
# V4
# Breaking changes in V6
The V4 edition of the action offers:
- Improve toolchain handling to ensure more reliable and consistent toolchain selection and management.
- Upgraded from node20Â to node24.
> Make sure your runner is on version v2.327.1 or later to ensure compatibility with this release. [See Release Notes](https://github.com/actions/runner/releases/tag/v2.327.1)
- Enabled caching by default
For more details, see the full release notes on the [releases page](https://github.com/actions/setup-go/releases/tag/v6.0.0)
The action will try to enable caching unless the `cache` input is explicitly set to false.
# V5
Please see "[Caching dependency files and build outputs](https://github.com/actions/setup-go#caching-dependency-files-and-build-outputs)" for more information.
The V5 edition of the action offers:
# V3
- Upgraded Node.js runtime from node16 to node20
The V3 edition of the action offers:
See full release notes on the [releases page](https://github.com/actions/setup-go/releases).
- Adds `GOBIN` to the `PATH`
- Proxy support
- Check latest version
- Caching packages dependencies
- stable and oldstable aliases
- Bug Fixes (including issues around version matching and semver)
The action will first check the local cache for a version match. If a version is not found locally, it will pull it from
The action will first check the local cache for a version match. If a version is not found locally, it will pull it from
the `main` branch of the [go-versions](https://github.com/actions/go-versions/blob/main/versions-manifest.json)
the `main` branch of the [go-versions](https://github.com/actions/go-versions/blob/main/versions-manifest.json)
@@ -42,8 +37,8 @@ Matching by [semver spec](https://github.com/npm/node-semver):
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version:'^1.13.1'# The Go version to download (if necessary) and use.
go-version:'^1.13.1'# The Go version to download (if necessary) and use.
- run:go version
- run:go version
@@ -51,26 +46,27 @@ steps:
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version:'>=1.17.0'
go-version:'>=1.17.0'
- run:go version
- run:go version
```
```
> **Note**: Due to the peculiarities of YAML parsing, it is recommended to wrap the version in single quotation marks:
> **Note**: Due to the peculiarities of YAML parsing, it is recommended to wrap the version in single quotation marks:
>
>
> ```yaml
> ```yaml
> go-version: '1.20'
> go-version: '1.20'
> ```
> ```
>
>
> The recommendation is based on the YAML parser's behavior, which interprets non-wrapped values as numbers and, in the case of version 1.20, trims it down to 1.2, which may not be very obvious.
> The recommendation is based on the YAML parser's behavior, which interprets non-wrapped values as numbers and, in the case of version 1.20, trims it down to 1.2, which may not be very obvious.
Matching an unstable pre-release:
Matching an unstable pre-release:
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version:'1.18.0-rc.1'# The Go version to download (if necessary) and use.
go-version:'1.18.0-rc.1'# The Go version to download (if necessary) and use.
- run:go version
- run:go version
@@ -78,8 +74,8 @@ steps:
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version:'1.16.0-beta.1'# The Go version to download (if necessary) and use.
go-version:'1.16.0-beta.1'# The Go version to download (if necessary) and use.
- run:go version
- run:go version
@@ -93,8 +89,8 @@ See [action.yml](action.yml)
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version:'1.16.1'# The Go version to download (if necessary) and use.
go-version:'1.16.1'# The Go version to download (if necessary) and use.
- run:go run hello.go
- run:go run hello.go
@@ -114,8 +110,8 @@ want the most up-to-date Go version to always be used.
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version:'1.14'
go-version:'1.14'
check-latest:true
check-latest:true
@@ -135,8 +131,8 @@ set to `true`
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version:'stable'
go-version:'stable'
- run:go run hello.go
- run:go run hello.go
@@ -144,8 +140,8 @@ steps:
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version:'oldstable'
go-version:'oldstable'
- run:go run hello.go
- run:go run hello.go
@@ -159,38 +155,50 @@ The `cache` input is optional, and caching is turned on by default.
The action defaults to search for the dependency file - go.sum in the repository root, and uses its hash as a part of
The action defaults to search for the dependency file - go.sum in the repository root, and uses its hash as a part of
the cache key. Use `cache-dependency-path` input for cases when multiple dependency files are used, or they are located
the cache key. Use `cache-dependency-path` input for cases when multiple dependency files are used, or they are located
in different subdirectories.
in different subdirectories. The input supports glob patterns.
If some problem that prevents success caching happens then the action issues the warning in the log and continues the execution of the pipeline.
If some problem that prevents success caching happens then the action issues the warning in the log and continues the execution of the pipeline.
**Caching in monorepos**
**Caching in monorepos**
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version:'1.17'
go-version:'1.17'
check-latest:true
check-latest:true
cache-dependency-path:subdir/go.sum
cache-dependency-path:|
subdir/go.sum
tools/go.sum
# cache-dependency-path: "**/*.sum"
- run:go run hello.go
- run:go run hello.go
```
```
## Getting go version from the go.mod file
## Getting go version from the go.mod file
The `go-version-file` input accepts a path to a `go.mod` file or a `go.work` file that contains the version of Go to be
The `go-version-file` input accepts a path to a `go.mod` file or a `go.work`
used by a project. As the `go.mod` file contains only major and minor (e.g. 1.18) tags, the action will search for the
file that contains the version of Go to be used by a project. The version taken
latest available patch version sequentially in the runner's directory with the cached tools, in
from thils file will be:
the [versions-manifest.json](https://github.com/actions/go-versions/blob/main/versions-manifest.json) file or at the go
servers.
- The version from the `toolchain` directive, if there is one, otherwise
- The version from the `go` directive
The version can specify a patch version or omit it altogether (e.g., `go 1.22.0` or `go 1.22`).
If a patch version is specified, that specific patch version will be used.
If no patch version is specified, it will search for the latest available patch version in the cache,
[versions-manifest.json](https://github.com/actions/go-versions/blob/main/versions-manifest.json), and the
[official Go language website](https://golang.org/dl/?mode=json&include=all), in that order.
If both the `go-version` and the `go-version-file` inputs are provided then the `go-version` input is used.
If both the `go-version` and the `go-version-file` inputs are provided then the `go-version` input is used.
> The action will search for the `go.mod` file relative to the repository root
> The action will search for the `go.mod` file relative to the repository root
```yaml
```yaml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- uses:actions/setup-go@v4
- uses:actions/setup-go@v6
with:
with:
go-version-file:'path/to/go.mod'
go-version-file:'path/to/go.mod'
- run:go version
- run:go version
@@ -207,9 +215,9 @@ jobs:
go:['1.14','1.13']
go:['1.14','1.13']
name:Go ${{ matrix.go }} sample
name:Go ${{ matrix.go }} sample
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v5
- name:Setup go
- name:Setup go
uses:actions/setup-go@v4
uses:actions/setup-go@v6
with:
with:
go-version:${{ matrix.go }}
go-version:${{ matrix.go }}
- run:go run hello.go
- run:go run hello.go
@@ -227,31 +235,35 @@ documentation.
## Using `setup-go` on GHES
## Using `setup-go` on GHES
`setup-go` comes pre-installed on the appliance with GHES if Actions is enabled. When dynamically downloading Go
`setup-go` comes pre-installed on the appliance with GHES if Actions is enabled.
distributions, `setup-go` downloads distributions from [`actions/go-versions`](https://github.com/actions/go-versions)
When dynamically downloading Go distributions, `setup-go` downloads distributions from [`actions/go-versions`](https://github.com/actions/go-versions) on github.com (outside of the appliance).
on github.com (outside of the appliance). These calls to `actions/go-versions` are made via unauthenticated requests,
which are limited
to [60 requests per hour per IP](https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting). If
more requests are made within the time frame, then you will start to see rate-limit errors during downloading that looks
like: `##[error]API rate limit exceeded for...`. After that error the action will try to download versions directly
from https://storage.googleapis.com/golang, but it also can have rate limit so it's better to put token.
To get a higher rate limit, you
These calls to `actions/go-versions` are made via unauthenticated requests, which are limited to [60 requests per hour per IP](https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting).
can [generate a personal access token on github.com](https://github.com/settings/tokens/new) and pass it as the `token`
If more requests are made within the time frame, then the action leverages the `raw API` to retrieve the version-manifest. This approach does not impose a rate limit and hence facilitates unrestricted consumption. This is particularly beneficial for GHES runners, which often share the same IP, to avoid the quick exhaustion of the unauthenticated rate limit.
input for the action:
If that fails as well the action will try to download versions directly from https://storage.googleapis.com/golang.
If that fails as well you can get a higher rate limit with [generating a personal access token on github.com](https://github.com/settings/tokens/new) and passing it as the `token` input to the action:
```yaml
```yaml
uses:actions/setup-go@v4
uses:actions/setup-go@v6
with:
with:
token:${{ secrets.GH_DOTCOM_TOKEN }}
token:${{ secrets.GH_DOTCOM_TOKEN }}
go-version:'1.18'
go-version:'1.18'
```
```
If the runner is not able to access github.com, any Go versions requested during a workflow run must come from the
If the runner is not able to access github.com, any Go versions requested during a workflow run must come from the runner's tool cache.
runner's tool cache.
See "[Setting up the tool cache on self-hosted runners without internet access](https://docs.github.com/en/enterprise-server@3.2/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access)"
See "[Setting up the tool cache on self-hosted runners without internet access](https://docs.github.com/en/enterprise-server@3.2/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access)"
for more information.
for more information.
## Recommended permissions
When using the `setup-go` action in your GitHub Actions workflow, it is recommended to set the following permissions to ensure proper functionality:
```yaml
permissions:
contents:read# access to check out code and install dependencies
```
# License
# License
The scripts and documentation in this project are released under the [MIT License](LICENSE)
The scripts and documentation in this project are released under the [MIT License](LICENSE)
`actions/setup-go` is the one of the most popular action related to Golang in GitHub Actions. Many customers use it in conjunction with [actions/cache](https://github.com/actions/cache) to speed up dependency installation process.
`actions/setup-go` is the one of the most popular action related to Golang in GitHub Actions. Many customers use it in conjunction with [actions/cache](https://github.com/actions/cache) to speed up dependency installation process.
See more examples on proper usage in [actions/cache documentation](https://github.com/actions/cache/blob/main/examples.md#go---modules).
See more examples on proper usage in [actions/cache documentation](https://github.com/actions/cache/blob/main/examples.md#go---modules).
# Goals & Anti-Goals
# Goals & Anti-Goals
@@ -16,7 +16,7 @@ Integration of caching functionality into `actions/setup-go` action will bring t
We don't pursue the goal to provide wide customization of caching in scope of `actions/setup-go` action. The purpose of this integration is covering ~90% of basic use-cases. If user needs flexible customization, we should advice them to use `actions/cache` directly.
We don't pursue the goal to provide wide customization of caching in scope of `actions/setup-go` action. The purpose of this integration is covering ~90% of basic use-cases. If user needs flexible customization, we should advice them to use `actions/cache` directly.
# Decision
# Decision
- Add `cache` input parameter to `actions/setup-go`. For now, input will accept the following values:
- Add `cache` input parameter to `actions/setup-go`. For now, input will accept the following values:
-`true` - enable caching for go dependencies
-`true` - enable caching for go dependencies
-`false`- disable caching for go dependencies. This value will be set as default value
-`false`- disable caching for go dependencies. This value will be set as default value
- Cache feature will be disabled by default to make sure that we don't break existing customers. We will consider enabling cache by default in next major releases
- Cache feature will be disabled by default to make sure that we don't break existing customers. We will consider enabling cache by default in next major releases
@@ -32,7 +32,7 @@ We don't pursue the goal to provide wide customization of caching in scope of `a
```yml
```yml
steps:
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v4
- uses:actions/setup-go@v3
- uses:actions/setup-go@v3
with:
with:
go-version:'18'
go-version:'18'
@@ -43,7 +43,7 @@ steps:
```yml
```yml
steps:
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v4
- uses: actions/setup-go@v3
- uses: actions/setup-go@v3
with:
with:
go-version: '18'
go-version: '18'
@@ -53,7 +53,7 @@ steps:
```yml
```yml
steps:
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v4
- uses: actions/setup-go@v3
- uses: actions/setup-go@v3
with:
with:
go-version: '18'
go-version: '18'
@@ -66,4 +66,4 @@ steps:
# Release process
# Release process
As soon as functionality is implemented, we will release minor update of action. No need to bump major version since there are no breaking changes for existing users.
As soon as functionality is implemented, we will release minor update of action. No need to bump major version since there are no breaking changes for existing users.
After that, we will update [starter-workflows](https://github.com/actions/starter-workflows/blob/main/ci/go.yml)
After that, we will update [starter-workflows](https://github.com/actions/starter-workflows/blob/main/ci/go.yml)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
