* 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 -->
<!--- 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 -->
This action sets up a go environment for use in actions by:
This action sets up a Go environment for use in GitHub Actions by:
- Optionally downloading and caching a version of Go by version and adding to `PATH`.
- Registering problem matchers for error output.
- Optionally downloading and caching a version of Go by version and adding to PATH
- Registering problem matchers for error output
- Providing intelligent caching for Go modules and build outputs
# V4
The V4 edition of the action offers:
- Enabled caching by default
The action will try to enable caching unless the `cache` input is explicitly set to false.
Please see "[Caching dependency files and build outputs](https://github.com/actions/setup-go#caching-dependency-files-and-build-outputs)" for more information.
# V3
The V3 edition of the action offers:
- 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 `main` branch of the [go-versions](https://github.com/actions/go-versions/blob/main/versions-manifest.json)
repository. On miss or failure, it will fall back to downloading directly
from [go dist](https://go.dev/dl). To change the default behavior, please use
the [check-latest input](#check-latest-version).
**Note:** The `setup-go` action uses executable binaries which are built by Golang side. The action does not build
golang from source code.
Matching by [semver spec](https://github.com/npm/node-semver):
## Quick Start
```yaml
steps:
- uses:actions/checkout@v3
- uses:actions/setup-go@v4
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'^1.13.1'# The Go version to download (if necessary) and use.
go-version:'1.23'
- run:go version
```
## Breaking Changes
### V6 Changes
#### Node Runtime Upgrade
- **Upgraded from Node 20 to Node 24**
- ⚠️ **Action Required**: Ensure your runner is on version v2.327.1 or later for compatibility
- See [Release Notes](https://github.com/actions/runner/releases/tag/v2.327.1) for more details
#### Enhanced Go Toolchain Management
V6 introduces significant improvements for reliable and consistent Go version selection:
**Toolchain Directive Support**
Now correctly interprets both `go` and `toolchain` directives from `go.mod`:
```go
go1.23.0// Minimum required version
toolchaingo1.23.2// V6 uses this exact version
```
**Intelligent Caching**
Cache keys now incorporate the `toolchain` directive version from `go.mod`, eliminating cache conflicts when switching between different toolchain versions within the same Go minor release.
For more details, see the [full release notes](https://github.com/actions/setup-go/releases/tag/v6.0.0).
### V5 Changes
- **Upgraded Node.js runtime from node16 to node20**
- See [full release notes](https://github.com/actions/setup-go/releases) for complete details
## Version Resolution Behavior
The action follows this resolution order:
1.**Local cache** - Checks for a cached version match
2.**go-versions repository** - Pulls from the main branch of the [go-versions repository](https://github.com/actions/go-versions/blob/main/versions-manifest.json)
3.**Direct download** - Falls back to downloading directly from [go.dev](https://go.dev/dl)
To change the default behavior, use the `check-latest` input.
> **Note**: The setup-go action uses executable binaries built by the Golang team. The action does not build golang from source code.
## Usage
### Basic Setup
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'1.23'
- run:go run hello.go
```
### Version Specifications
#### Semantic Versioning
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'^1.23.1'# The Go version to download (if necessary) and use.
- run:go version
```
```yaml
steps:
- uses:actions/checkout@v3
- uses:actions/setup-go@v4
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'>=1.17.0'
go-version:'>=1.22.0'
- run:go version
```
> **Note**: Due to the peculiarities of YAML parsing, it is recommended to wrap the version in single quotation marks:
>
> **Important**: Due to YAML parsing behavior, always wrap version numbers in single quotes:
> ```yaml
> 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.
go-version:'1.18.0-rc.1'# The Go version to download (if necessary) and use.
go-version:'1.24.0-rc.1'# The Go version to download (if necessary) and use
- run:go version
```
```yaml
# Beta version
steps:
- uses:actions/checkout@v3
- uses:actions/setup-go@v4
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'1.16.0-beta.1'# The Go version to download (if necessary) and use.
go-version:'1.23.0-beta.1'# The Go version to download (if necessary) and use
- run:go version
```
# Usage
#### Version Aliases
See [action.yml](action.yml)
**Stable Release**
## Basic
If `stable` is provided, action will get the latest stable version from the [go-versions](https://github.com/actions/go-versions/blob/main/versions-manifest.json) repository manifest.
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'stable'# Latest stable version
- run:go version
```
**Previous Stable Release**
If `oldstable` is provided, when the current release is 1.23.x, the action will resolve version as 1.22.x, where x is the latest patch release.
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'oldstable'# Previous stable version
- run:go version
```
> **Note**: Using aliases is equivalent to using the corresponding minor release with `check-latest: true`
### go-version-file
The action can automatically detect the Go version from various project files using the `go-version-file` input. This parameter supports `go.mod`, `go.work`, `.go-version`, and `.tool-versions` files.
> **Note**: If both `go-version` and `go-version-file` are provided, `go-version` takes precedence.
#### go.mod File
Automatically detect the Go version from your project's `go.mod` file:
```yaml
steps:
- uses:actions/checkout@v3
- uses:actions/setup-go@v4
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'1.16.1'# The Go version to download (if necessary) and use.
go-version-file:'go.mod'
- run:go version
```
**Version Resolution from go.mod:**
1. Uses the `toolchain` directive version if present
2. Falls back to the `go` directive version
3. If no patch version is specified, uses the latest available patch
#### go.work File
Use the Go version specified in your `go.work` file:
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version-file:'go.work'
- run:go version
```
#### .go-version File
Read the Go version from a `.go-version` file:
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version-file:'.go-version'
- run:go version
```
#### .tool-versions File
Use the Go version from an [`.tool-versions`](https://asdf-vm.com/manage/configuration.html#tool-versions) file:
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version-file:'.tool-versions'
- run:go version
```
#### Custom File Paths
The action searches for version files relative to the repository root by default. You can specify a custom path:
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version-file:'path/to/.go-version'
- run:go version
```
**Supported Version Formats:**
- Major and minor only: `1.25` (action will use the latest patch version, e.g., `1.25.4`)
- Major, minor, and patch: `1.25.4` (exact version)
### Check Latest Version
The check-latest flag defaults to false for stability. This ensures your workflow uses a specific, predictable Go version.
When `check-latest: true`, the action verifies if your cached Go version is the latest available. If not, it downloads and uses the newest version.
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'1.23'
check-latest:true# Always check for the latest patch release
- run:go version
```
**Performance Considerations:**
-`check-latest: false` (default) - Uses cached versions for faster builds
-`check-latest: true` - Downloads the latest version, slower but ensures up-to-date releases
### Caching
The action features integrated caching for Go modules and build outputs. Built on [toolkit/cache](https://github.com/actions/toolkit/tree/main/packages/cache), it simplifies the caching process by requiring fewer configuration options. The cache input is optional, and caching is turned on by default.
#### Automatic Caching
Default behavior: Searches for `go.sum` in the repository root and uses its hash for the cache key.
```yaml
steps:
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'1.23'
# cache: true (default)
- run:go run hello.go
```
## Check latest version
#### Advanced Caching Scenarios
The `check-latest` flag defaults to `false`. Use the default or set`check-latest` to `false` if you prefer stability
and if you want to ensure a specific Go version is always used.
If `check-latest` is set to `true`, the action first checks if the cached version is the latest one. If the locally
cached version is not the most up-to-date, a Go version will then be downloaded. Set `check-latest` to `true` if you
want the most up-to-date Go version to always be used.
> Setting `check-latest` to `true` has performance implications as downloading Go versions is slower than using cached
> versions.
For advanced scenarios, use `cache-dependency-path` to specify:
- **Multiple dependency files**: When your project has dependencies in different directories
- **Custom locations**: When your `go.sum` files are not in the repository root
- **Monorepos**: When managing multiple Go modules in a single repository
- **Glob patterns**: For flexible file matching
```yaml
# Example: Monorepo with multiple go.sum files
steps:
- uses:actions/checkout@v3
- uses:actions/setup-go@v4
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'1.14'
go-version:'1.23'
check-latest:true
- run:go run hello.go
```
## Using stable/oldstable aliases
If `stable` is provided, action will get the latest stable version from
the [`go-versions`](https://github.com/actions/go-versions/blob/main/versions-manifest.json) repository manifest.
If `oldstable` is provided, when current release is 1.19.x, action will resolve version as 1.18.x, where x is the latest
patch release.
**Note:** using these aliases will result in same version as using corresponding minor release with `check-latest` input
set to `true`
```yaml
steps:
- uses:actions/checkout@v3
- uses:actions/setup-go@v4
with:
go-version:'stable'
cache-dependency-path:|
subdir/go.sum
tools/go.sum
- run:go run hello.go
```
```yaml
# Example: Using glob patterns to match all go.sum files
steps:
- uses:actions/checkout@v3
- uses:actions/setup-go@v4
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'oldstable'
go-version:'1.23'
cache-dependency-path:"**/*.sum"
- run:go run hello.go
```
## Caching dependency files and build outputs:
The action has a built-in functionality for caching and restoring go modules and build outputs. It
uses [toolkit/cache](https://github.com/actions/toolkit/tree/main/packages/cache) under the hood but requires less configuration settings.
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 cache key. Use `cache-dependency-path` input for cases when multiple dependency files are used, or they are located
in different subdirectories.
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**
#### Disable Caching
```yaml
steps:
- uses:actions/checkout@v3
- uses:actions/setup-go@v4
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:'1.17'
check-latest:true
cache-dependency-path:subdir/go.sum
go-version:'1.23'
cache:false
- run:go run hello.go
```
## 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
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
latest available patch version sequentially in the runner's directory with the cached tools, in
the [versions-manifest.json](https://github.com/actions/go-versions/blob/main/versions-manifest.json) file or at the go
servers.
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
```yaml
steps:
- uses:actions/checkout@v3
- uses:actions/setup-go@v4
with:
go-version-file:'path/to/go.mod'
- run:go version
```
## Matrix testing
> **Note**: If caching fails, the action logs a warning but continues execution without interrupting your workflow.
### Matrix Testing
Test across multiple Go versions:
```yaml
jobs:
build:
test:
runs-on:ubuntu-latest
strategy:
matrix:
go:['1.14','1.13']
name:Go ${{ matrix.go }} sample
go-version:['1.21','1.22','1.23']
steps:
- uses:actions/checkout@v3
- name:Setupgo
uses:actions/setup-go@v4
- uses:actions/checkout@v5
- uses:actions/setup-go@v6
with:
go-version:${{ matrix.go }}
- run:go run hello.go
go-version:${{ matrix.go-version }}
- run:go test ./...
```
### Supported version syntax
## Advanced Configuration
### Supported Version Syntax
The `go-version` input supports the following syntax:
- Specific versions: `1.15`, `1.16.1`, `1.17.0-rc.2`, `1.16.0-beta.1`
- SemVer's version range syntax: `^1.13.1`, `>=1.18.0-rc.1`
| Syntax Type | Example | Description |
|-------------|---------|-------------|
| Specific version | `1.23.2` | Installs this exact version |
For more information about semantic versioning, please refer to [semver](https://github.com/npm/node-semver)
documentation.
For more information about semantic versioning, see the [semver documentation](https://semver.org/).
## Using `setup-go` on GHES
`setup-go` comes pre-installed on the appliance with GHES if Actions is enabled. 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). 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://go.dev/dl, but it also can have rate limit so it's better to put token.
To get a higher rate limit, you
can [generate a personal access token on github.com](https://github.com/settings/tokens/new) and pass it as the `token`
input for the action:
### Complete Input Reference
```yaml
uses:actions/setup-go@v4
with:
token:${{ secrets.GH_DOTCOM_TOKEN }}
go-version:'1.18'
- uses:actions/setup-go@v6
with:
# Version or version range of Go to use
go-version:'1.23'
# Path to go.mod, go.work, .go-version, or .tool-versions file
go-version-file:'go.mod'
# Check for latest version
check-latest:false
# GitHub token for authentication
token:${{ github.token }}
# Enable/disable caching
cache:true
# Path to dependency files for caching
cache-dependency-path:'go.sum'
# Architecture to install (auto-detected if not specified)
architecture:'x64'
```
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.
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.
## Using setup-go on GHES
# License
setup-go comes pre-installed on GHES when Actions is enabled. For dynamic Go version downloads, the action fetches distributions from the [go-versions repository](https://github.com/actions/go-versions/) on github.com (external to your appliance).
The scripts and documentation in this project are released under the [MIT License](LICENSE)
These calls to `actions/go-versions` are made via unauthenticated requests, which are limited to 60 requests per hour per IP. 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. If that fails as well the action will try to download versions directly from [go.dev](https://go.dev/dl).
# Contributions
If that fails as well you can get a higher rate limit with generating a personal access token on github.com and passing it as the token input to the action:
Contributions are welcome! See [Contributor's Guide](docs/contributors.md)
```yaml
uses:actions/setup-go@v6
with:
token:${{ secrets.GH_DOTCOM_TOKEN }}
go-version:'1.23'
```
### Offline Runners
For runners without github.com access, Go versions must be pre-cached in the 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)".
## 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# Required to checkout code and install dependencies
```
## License
The scripts and documentation in this project are released under the [MIT License](LICENSE).
## Contributions
Contributions are welcome! See our [Contributor's Guide](docs/contributors.md) for details.
## Code of Conduct
:wave: Be nice. See [our code of conduct](CODE_OF_CONDUCT.md)
👋 Be nice. See our [Code of Conduct](CODE_OF_CONDUCT.md).
description:'The Go version to download (if necessary) and use. Supports semver spec and ranges. Be sure to enclose this option in single quotation marks.'
go-version-file:
description:'Path to the go.mod or go.work file.'
description:'Path to the go.mod, go.work, .go-version, or .tool-versions file.'
check-latest:
description:'Set this option to true if you want the action to always check for the latest available version that satisfies the version spec'
default:false
@@ -25,7 +25,7 @@ outputs:
cache-hit:
description:'A boolean value to indicate if a cache was hit'
`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).
# 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.
# 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
-`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
@@ -32,7 +32,7 @@ We don't pursue the goal to provide wide customization of caching in scope of `a
```yml
steps:
- uses:actions/checkout@v3
- uses:actions/checkout@v4
- uses:actions/setup-go@v3
with:
go-version:'18'
@@ -43,7 +43,7 @@ steps:
```yml
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v4
- uses: actions/setup-go@v3
with:
go-version: '18'
@@ -53,7 +53,7 @@ steps:
```yml
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v4
- uses: actions/setup-go@v3
with:
go-version: '18'
@@ -66,4 +66,4 @@ steps:
# 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.
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.
