go/goreleaser
1
0
Fork 0
mirror of https://github.com/goreleaser/goreleaser.git synced 2025-09-16 09:26:52 +02:00
Code Issues Releases Activity

docs: improve wording/formatting in several places (#3384)

Browse Source 
this just improves docs wording and formatting in several places.

Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
This commit is contained in:
Carlos Alexandro Becker
2022-09-17 00:13:09 -03:00
committed by GitHub
parent 36a48eabb7
commit c1965923b0
33 changed files with 499 additions and 353 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
internal/pipe/git/errors.go
View File

@@ -11,7 +11,7 @@ type ErrDirty struct {
}
func (e ErrDirty) Error() string {
return fmt.Sprintf("git is currently in a dirty state\nPlease check in your pipeline what can be changing the following files:\n%v\nLearn more at https://goreleaser.com/errors/dirty\n", e.status)
return fmt.Sprintf("git is in a dirty state\nPlease check in your pipeline what can be changing the following files:\n%v\nLearn more at https://goreleaser.com/errors/dirty\n", e.status)
}
// ErrWrongRef happens when the HEAD reference is different from the tag being built.

73
www/docs/ci/actions.md
View File

@@ -1,10 +1,10 @@
# GitHub Actions
GoReleaser can also be used within our official [GoReleaser Action][goreleaser-action]
through [GitHub Actions][actions].
GoReleaser can also be used within our official [GoReleaser
Action][goreleaser-action] through [GitHub Actions][actions].
You can create a workflow for pushing your releases by putting YAML configuration to
`.github/workflows/release.yml`.
You can create a workflow for pushing your releases by putting YAML
configuration to `.github/workflows/release.yml`.
## Usage
@@ -77,8 +77,8 @@ jobs:
### Signing
If [signing is enabled][signing] in your GoReleaser configuration, you can use the [Import GPG][import-gpg]
GitHub Action along with this one:
If [signing is enabled][signing] in your GoReleaser configuration, you can use
the [Import GPG][import-gpg] GitHub Action along with this one:
```yaml
-
@@ -99,7 +99,8 @@ GitHub Action along with this one:
GPG_FINGERPRINT: ${{ steps.import_gpg.outputs.fingerprint }}
```
And reference the fingerprint in your signing configuration using the `GPG_FINGERPRINT` environment variable:
And reference the fingerprint in your signing configuration using the
`GPG_FINGERPRINT` environment variable:
```yaml
signs:
@@ -109,54 +110,64 @@ signs:
## Customizing
<!-- to format the tables, use: https://tabletomarkdown.com/format-markdown-table/ -->
### Inputs
Following inputs can be used as `step.with` keys
| Name | Type | Default | Description |
|------------------|---------|--------------|------------------------------------------------------------------|
| `distribution` | String | `goreleaser` | GoReleaser distribution, either `goreleaser` or `goreleaser-pro` |
| `version`[^1] | String | `latest` | GoReleaser version |
| `args` | String | | Arguments to pass to GoReleaser |
| `workdir` | String | `.` | Working directory (below repository root) |
| `install-only` | Bool | `false` | Just install GoReleaser |
Name |Type |Default |Description
--------------|------|------------|----------------------------------------------------------------
`distribution`|String|`goreleaser`|GoReleaser distribution, either `goreleaser` or `goreleaser-pro`
`version`[^1] |String|`latest` |GoReleaser version
`args` |String| |Arguments to pass to GoReleaser
`workdir` |String|`.` |Working directory (below repository root)
`install-only`|Bool |`false` |Just install GoReleaser
[^1]: Can be a fixed version like `v0.117.0` or a max satisfying SemVer one like `~> 0.132`. In this case this will return `v0.132.1`.
[^1]: Can be a fixed version like `v0.117.0` or a max satisfying SemVer one like
`~> 0.132`. In this case this will return `v0.132.1`.
### Outputs
Following outputs are available
| Name | Type | Description |
|-------------------|---------|---------------------------------------|
| `artifacts` | JSON | Build result artifacts |
| `metadata` | JSON | Build result metadata |
Name |Type|Description
-----------|----|----------------------
`artifacts`|JSON|Build result artifacts
`metadata` |JSON|Build result metadata
### Environment Variables
Following environment variables can be used as `step.env` keys
| Name | Description |
|------------------|---------------------------------------|
| `GITHUB_TOKEN` | [GITHUB_TOKEN](https://help.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token) as provided by `secrets` |
| `GORELEASER_KEY` | Your [GoReleaser Pro](https://goreleaser.com/pro) License Key, in case you are using the `goreleaser-pro` distribution |
Name |Description
----------------|---------------------------------------------------------------------------------------------------------------------------------------------------
`GITHUB_TOKEN` |[GITHUB_TOKEN](https://help.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token) as provided by `secrets`
`GORELEASER_KEY`|Your [GoReleaser Pro](https://goreleaser.com/pro) License Key, in case you are using the `goreleaser-pro` distribution
## Token Permissions
The following [permissions](https://docs.github.com/en/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token) are required by GoReleaser:
The following
[permissions](https://docs.github.com/en/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)
are required by GoReleaser:
- `contents: write` if you wish to
- [upload archives as GitHub Releases](/customization/release/), or
- publish to [Homebrew](/customization/homebrew/), or [Scoop](/customization/scoop/) (assuming it's part of the same repository)
- publish to [Homebrew](/customization/homebrew/), or
[Scoop](/customization/scoop/) (assuming it's part of the same repository)
- or just `contents: read` if you don't need any of the above
- `packages: write` if you [push Docker images](/customization/docker/) to GitHub
- `issues: write` if you use [milestone closing capability](/customization/milestone/)
- `packages: write` if you [push Docker images](/customization/docker/) to
GitHub
- `issues: write` if you use [milestone closing
capability](/customization/milestone/)
`GITHUB_TOKEN` permissions [are limited to the repository][about-github-token] that contains your workflow.
`GITHUB_TOKEN` permissions [are limited to the repository][about-github-token]
that contains your workflow.
If you need to push the homebrew tap to another repository, you must create a custom
[Personal Access Token][pat] with `repo` permissions and [add it as a secret in the repository][secrets]. If you
create a secret named `GH_PAT`, the step will look like this:
If you need to push the homebrew tap to another repository, you must create a
custom [Personal Access Token][pat] with `repo` permissions and [add it as a
secret in the repository][secrets]. If you create a secret named `GH_PAT`, the
step will look like this:
```yaml
-

33
www/docs/ci/azurepipelines.md
View File

@@ -1,7 +1,7 @@
# Azure Pipelines
GoReleaser can also be used within our official [GoReleaser Extensions for Azure DevOps][goreleaser-extension]
through [Visual Studio marketplace][marketplace].
GoReleaser can also be used within our official [GoReleaser Extensions for Azure
DevOps][goreleaser-extension] through [Visual Studio marketplace][marketplace].
### Task definition
@@ -16,18 +16,21 @@ through [Visual Studio marketplace][marketplace].
### Task inputs
Following inputs can be used
Following inputs can be used:
| Name | Type | Default | Description |
|------------------|---------|--------------|------------------------------------------------------------------|
| `distribution` | String | `goreleaser` | GoReleaser distribution, either `goreleaser` or `goreleaser-pro` |
| `version`[^version] | String | `latest` | GoReleaser version |
| `args` | String | | Arguments to pass to GoReleaser |
| `workdir` | String | `$(Build.SourcesDirectory)` | Working directory (below repository root) |
| `installOnly` | Bool | `false` | Just install GoReleaser |
<!-- to format the tables, use: https://tabletomarkdown.com/format-markdown-table/ -->
Name |Type |Default |Description
-------------------|------|---------------------------|----------------------------------------------------------------
`distribution` |String|`goreleaser` |GoReleaser distribution, either `goreleaser` or `goreleaser-pro`
`version`[^version]|String|`latest` |GoReleaser version
`args` |String| |Arguments to pass to GoReleaser
`workdir` |String|`$(Build.SourcesDirectory)`|Working directory (below repository root)
`installOnly` |Bool |`false` |Just install GoReleaser
[^version]: Can be a fixed version like `v1.10.0` or a max satisfying semver one like `~> v1.10`. In this case this will return the latest patch release of `v1.10`. For the `pro` version, add `-pro` to the string
[^version]: Can be a fixed version like `v1.10.0` or a max satisfying semver one
like `~> v1.10`. In this case this will return the latest patch release of
`v1.10`. For the `pro` version, add `-pro` to the string
### Task environment variables
@@ -48,10 +51,10 @@ variables:
Following environment variables can be used, as environment variable.
| Name | Description |
|------------------|---------------------------------------|
| `GITHUB_TOKEN` | [GITHUB_TOKEN](https://help.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token) for e.g. `brew` |
| `GORELEASER_KEY` | Your [GoReleaser Pro](https://goreleaser.com/pro) License Key, in case you are using the `goreleaser-pro` distribution |
Name |Description
----------------|------------------------------------------------------------------------------------------------------------------------------------------
`GITHUB_TOKEN` |[GITHUB_TOKEN](https://help.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token) for e.g. `brew`
`GORELEASER_KEY`|Your [GoReleaser Pro](https://goreleaser.com/pro) License Key, in case you are using the `goreleaser-pro` distribution
### Example pipeline

14
www/docs/customization/artifactory.md
View File

@@ -10,7 +10,7 @@ each configured Artifactory.
If you have only one Artifactory instance,
the configuration is as easy as adding the
upload target and a username to your `.goreleaser.yaml` file:
upload target, and a username to your `.goreleaser.yaml` file:
```yaml
artifactories:
@@ -53,13 +53,11 @@ Supported variables:
Your configured username needs to be authenticated against your Artifactory.
You can have the username set in the configuration file as shown above
or you can have it read from an environment variable.
The configured name of your Artifactory instance will be used to build
the environment variable name.
This way we support auth for multiple instances.
This also means that the `name` per configured instance needs to be unique
per goreleaser configuration.
You can have the username set in the configuration file as shown above, or you
can have it read from an environment variable. The configured name of your
Artifactory instance will be used to build the environment variable name. This
way we support authentication for multiple instances. This also means that the
`name` per configured instance needs to be unique per GoReleaser configuration.
The name of the environment variable will be `ARTIFACTORY_NAME_USERNAME`.
If your instance is named `production`, you can store the username in the

2
www/docs/customization/aur.md
View File

@@ -56,7 +56,7 @@ aurs:
# The SSH private key that should be used to commit to the Git repository.
# This can either be a path or the key contents.
#
# WARNING: do not expose your private key in the config file!
# WARNING: do not expose your private key in the configuration file!
private_key: '{{ .Env.AUR_KEY }}'
# The AUR Git URL for this package.

2
www/docs/customization/blob.md
View File

@@ -84,7 +84,7 @@ chain in the following order:
### Azure Blob Provider
Currently it supports authentication only with
It supports authentication only with
[environment variables](https://docs.microsoft.com/en-us/azure/storage/common/storage-azure-cli#set-default-azure-storage-account-environment-variables):
- `AZURE_STORAGE_ACCOUNT`

31
www/docs/customization/build.md
View File

@@ -257,13 +257,15 @@ builds:
The binary name field supports [templating](/customization/templates/). The following build details are exposed:
| Key | Description |
|---------|----------------------------------|
| .Os | `GOOS` |
| .Arch | `GOARCH` |
| .Arm | `GOARM` |
| .Ext | Extension, e.g. `.exe` |
| .Target | Build target, e.g. `darwin_amd64`|
<!-- to format the tables, use: https://tabletomarkdown.com/format-markdown-table/ -->
Key |Description
-------|---------------------------------
.Os |`GOOS`
.Arch |`GOARCH`
.Arm |`GOARM`
.Ext |Extension, e.g. `.exe`
.Target|Build target, e.g. `darwin_amd64`
## Passing environment variables to ldflags
@@ -333,12 +335,15 @@ All properties of a hook (`cmd`, `dir` and `env`) support [templating](/customiz
with `post` hooks having binary artifact available (as these run _after_ the build).
Additionally the following build details are exposed to both `pre` and `post` hooks:
| Key | Description |
|---------|----------------------------------------|
| .Name | Filename of the binary, e.g. `bin.exe` |
| .Ext | Extension, e.g. `.exe` |
| .Path | Absolute path to the binary |
| .Target | Build target, e.g. `darwin_amd64` |
<!-- to format the tables, use: https://tabletomarkdown.com/format-markdown-table/ -->
Key |Description
-------|--------------------------------------
.Name |Filename of the binary, e.g. `bin.exe`
.Ext |Extension, e.g. `.exe`
.Path |Absolute path to the binary
.Target|Build target, e.g. `darwin_amd64`
Environment variables are inherited and overridden in the following order:

37
www/docs/customization/docker_manifest.md
View File

@@ -1,19 +1,22 @@
# Docker Manifests
GoReleaser can also create and push Docker multi-platform images using the `docker manifest` tool.
GoReleaser can also create and push Docker multi-platform images using the
`docker manifest` tool.
For it to work, it needs to be enabled in the [client's configuration](https://github.com/docker/cli/blob/master/experimental/README.md).
For it to work, it needs to be enabled in the
[client's configuration](https://github.com/docker/cli/blob/master/experimental/README.md).
Please make sure `docker manifest` works before opening issues.
Notice that if you have something in the `docker_manifests` section in your
config file, GoReleaser will add the manifest's to the release notes
instead of the Docker images names.
config file, GoReleaser will add the manifest's to the release notes instead of
the Docker images names.
!!! warning
Notice that the images used in the manifest **need to be pushed** for this to work.
This is a limitation of how `docker manifest create` works.
For more info, check [this issue](https://github.com/goreleaser/goreleaser/issues/2606).
Notice that the images used in the manifest **need to be pushed** for this
to work. This is a limitation of how `docker manifest create` works. For
more info, check
[this issue](https://github.com/goreleaser/goreleaser/issues/2606).
## Customization
@@ -25,7 +28,8 @@ options available:
docker_manifests:
# You can have multiple Docker manifests.
-
# ID of the manifest, needed if you want to filter by it later on (e.g. on custom publishers).
# ID of the manifest, needed if you want to filter by it later on (e.g. on
# custom publishers).
id: myimg
# Name template for the manifest.
@@ -63,7 +67,8 @@ docker_manifests:
#
# Relevant notes:
# 1. podman is a GoReleaser Pro feature and is only available on Linux;
# 2. if you set podman here, the respective docker configs need to use podman too.
# 2. if you set podman here, the respective docker configs need to use podman
# too.
#
# Defaults to docker.
use: docker
@@ -75,7 +80,7 @@ docker_manifests:
## How it works
We basically build and push our images as usual, but we also add a new
section to our config defining which images are part of which manifests.
section to our configuration defining, which images are part of which manifests.
GoReleaser will create and publish the manifest in its publishing phase.
@@ -86,7 +91,7 @@ GoReleaser will create and publish the manifest in its publishing phase.
## Example config
In this example we will use Docker's `--platform` option to specify the target platform.
This way we can use the same `Dockerfile` for both the `amd64` and the `arm64`
This way we can use the same `Dockerfile` for both the `amd64`, and the `arm64`
images (and possibly others):
```dockerfile
@@ -96,8 +101,8 @@ ENTRYPOINT ["/usr/bin/mybin"]
COPY mybin /usr/bin/mybin
```
Then, on our GoReleaser config file, we need to define both the `dockers` and
the `docker_manifests` section:
Then, on our GoReleaser configuration file, we need to define both the
`dockers`, and the `docker_manifests` section:
```yaml
# .goreleaser.yaml
@@ -142,7 +147,8 @@ and push everything to Docker Hub.
!!! success "GoReleaser Pro"
The podman backend is a [GoReleaser Pro feature](/pro/).
You can use [`podman`](https://podman.io) instead of `docker` by setting `use` to `podman` on your config:
You can use [`podman`](https://podman.io) instead of `docker` by setting `use`
to `podman` on your configuration:
```yaml
# .goreleaser.yaml
@@ -154,4 +160,5 @@ docker_manifests:
use: podman
```
Note that GoReleaser will not install Podman for you, nor change any of its configuration.
Note that GoReleaser will not install Podman for you, nor change any of its
configuration.

14
www/docs/customization/docker_sign.md
View File

@@ -1,10 +1,12 @@
# Signing Docker Images and Manifests
Signing Docker Images and Manifests is also possible with GoReleaser.
This pipe was designed based on the common [sign](/customization/sign/) pipe having [cosign](https://github.com/sigstore/cosign) in mind.
This pipe was designed based on the common [sign](/customization/sign/) pipe
having [cosign](https://github.com/sigstore/cosign) in mind.
!!! info
Note that this pipe will run only at the end of the GoReleaser execution (in its publish phase), as cosign will change the image in the registry.
Note that this pipe will run only at the end of the GoReleaser execution (in
its publishing phase), as cosign will change the image in the registry.
To customize the signing pipeline you can use the following options:
@@ -76,9 +78,11 @@ These environment variables might be available in the fields that are templateab
- `${artifact}`: the path to the artifact that will be signed [^1]
- `${artifactID}`: the ID of the artifact that will be signed
- `${certificate}`: the certificate filename, if provided
- `${certificate}`: the certificate file name, if provided
[^1]: notice that the this might contain `/` characters, which depending on how you use it might evaluate to actual paths within the filesystem. Use with care.
[^1]: notice that this might contain `/` characters, which depending on how
you use it might evaluate to actual paths within the file system. Use with
care.
## Common usage example
@@ -96,6 +100,6 @@ docker_signs:
Later on you (and anyone else) can verify the image with:
```sh
```bash
cosign verify --key cosign.pub your/image
```

6
www/docs/customization/env.md
View File

@@ -2,7 +2,8 @@
Global environment variables to be passed down to all hooks and builds.
If you have an environment variable named `FOOBAR` set to `on`, your `.goreleaser.yaml` file could use it like this:
If you have an environment variable named `FOOBAR` set to `on`, your
`.goreleaser.yaml` file could use it like this:
```yaml
# .goreleaser.yaml
@@ -16,7 +17,8 @@ builds:
- binary: program
```
This way, both your before hooks (in this example, `go mod tidy`) and the underlying builds (using `go build`) will have `FOO` set to `on`.
This way, both your before hooks (in this example, `go mod tidy`) and the
underlying builds (using `go build`) will have `FOO` set to `on`.
The root `env` section also accepts templates.

23
www/docs/customization/fury.md
View File

@@ -1,8 +1,9 @@
# Fury.io (apt and rpm repositories)
!!! success "GoReleaser Pro"
The fury.io publisher is a [GoReleaser Pro feature](/pro/).
You might be able to reproduce some of its behavior on GoReleaser OSS using [custom publishers](/customization/publishers/).
The fury.io publisher is a [GoReleaser Pro feature](/pro/). You might be
able to reproduce some of its behavior on GoReleaser OSS using
[custom publishers](/customization/publishers/).
You can easily create `deb` and `yum` repositories on [fury.io][fury] using GoReleaser.
@@ -10,7 +11,8 @@ You can easily create `deb` and `yum` repositories on [fury.io][fury] using GoRe
First, you need to create an account on [fury.io][fury] and get a push token.
Then, you need to pass your account name to GoReleaser and have your push token as an environment variable named `FURY_TOKEN`:
Then, you need to pass your account name to GoReleaser and have your push token
as an environment variable named `FURY_TOKEN`:
```yaml
# .goreleaser.yaml
@@ -33,18 +35,25 @@ furies:
# Config is skipped if empty
account: "{{ .Env.FURY_ACCOUNT }}"
# Skip the announcing feature in some conditions, for instance, when publishing patch releases.
# Valid options are `true`, `false`, empty, or a template that evaluates to a boolean (`true` or `false`).
# Skip the announcing feature in some conditions, for instance, when
# publishing patch releases.
# Valid options are `true`, `false`, empty, or a
# template that evaluates to a boolean (`true` or `false`).
#
# Defaults to empty - which means false.
skip: "{{gt .Patch 0}}"
# Environment variable name to get the push token from.
# You might want to change it if you have multiple fury configurations for some reason.
# You might want to change it if you have multiple fury configurations for
# some reason.
#
# Defaults to empty - which means false.
# Defaults to `FURY_TOKEN`.
secret_name: MY_ACCOUNT_FURY_TOKEN
# IDs to filter by.
# Defaults to empty, which means all packages created by all nfpm configurations get uploaded.
# Defaults to empty, which means all packages created by all nfpm
# configurations get uploaded.
ids:
- packages

29
www/docs/customization/homebrew.md
View File

@@ -5,7 +5,7 @@ a _homebrew-tap_ recipe into a repository that you have access to.
The `brews` section specifies how the formula should be created.
You can check the
[Homebrew documentation](https://github.com/Homebrew/brew/blob/master/docs/How-to-Create-and-Maintain-a-Tap.md)
[Homebrew documentation](https://github.com/Homebrew/brew/blob/master/docs/How-to-Create-and-Maintain-a-Tap.md),
and the
[formula cookbook](https://github.com/Homebrew/brew/blob/master/docs/Formula-Cookbook.md)
for more details.
@@ -24,18 +24,21 @@ brews:
- foo
- bar
# GOARM to specify which 32-bit arm version to use if there are multiple versions
# from the build section. Brew formulas support only one 32-bit version.
# GOARM to specify which 32-bit arm version to use if there are multiple
# versions from the build section. Brew formulas support only one 32-bit
# version.
# Default is 6 for all artifacts or each id if there a multiple versions.
goarm: 6
# GOAMD64 to specify which amd64 version to use if there are multiple versions
# from the build section.
# GOAMD64 to specify which amd64 version to use if there are multiple
# versions from the build section.
# Default is v1.
goamd64: v3
# NOTE: make sure the url_template, the token and given repo (github or gitlab) owner and name are from the
# same kind. We will probably unify this in the next major version like it is done with scoop.
# NOTE: make sure the url_template, the token and given repo (github or
# gitlab) owner and name are from the same kind.
# We will probably unify this in the next major version like it is
# done with scoop.
# GitHub/GitLab repository to push the formula to
tap:
@@ -46,10 +49,12 @@ brews:
# Defaults to the default repository branch.
branch: main
# Optionally a token can be provided, if it differs from the token provided to GoReleaser
# Optionally a token can be provided, if it differs from the token
# provided to GoReleaser
token: "{{ .Env.HOMEBREW_TAP_GITHUB_TOKEN }}"
# Template for the url which is determined by the given Token (github, gitlab or gitea)
# Template for the url which is determined by the given Token (github,
# gitlab or gitea)
#
# Default depends on the client.
url_template: "http://github.mycompany.com/foo/bar/releases/{{ .Tag }}/{{ .ArtifactName }}"
@@ -60,7 +65,8 @@ brews:
# Default is empty.
download_strategy: CurlDownloadStrategy
# Allows you to add a custom require_relative at the top of the formula template
# Allows you to add a custom require_relative at the top of the formula
# template.
# Default is empty
custom_require: custom_download_strategy
@@ -115,7 +121,8 @@ brews:
type: optional
- name: fish
version: v1.2.3
# if providing both version and type, only the type will be taken into account.
# if providing both version and type, only the type will be taken into
# account.
- name: elvish
type: optional
version: v1.2.3

24
www/docs/customization/hooks.md
View File

@@ -1,13 +1,15 @@
# Global Hooks
Some release cycles may need run something before or after everything else.
Some release cycles may need to run something before or after everything else.
GoReleaser allows this with the global hooks feature.
=== "OSS"
The `before` section allows for global hooks that will be executed **before** the release is started.
The `before` section allows for global hooks that will be executed
**before** the release is started.
The configuration is straightforward, here is an example will all possible options:
The configuration is straightforward, here is an example will all possible
options:
```yaml
# .goreleaser.yaml
@@ -22,12 +24,15 @@ GoReleaser allows this with the global hooks feature.
=== "Pro"
!!! success "GoReleaser Pro"
Global after hooks and the additional options in before hooks (`dir` and `env`) are [GoReleaser Pro features](/pro/).
Global after hooks, and the additional options in before hooks (`dir`
and `env`) are [GoReleaser Pro features](/pro/).
The `before` section allows for global hooks that will be executed **before** the release is started.
Likewise, the `after` section allows for global hooks that will be executed **after** the release is started.
The `before` section allows for global hooks that will be executed
**before** the release is started. Likewise, the `after` section allows for
global hooks that will be executed **after** the release is started.
The configuration is straightforward, here is an example will all possible options:
The configuration is straightforward, here is an example will all possible
options:
```yaml
# .goreleaser.yaml
@@ -61,8 +66,9 @@ Note that if any of the hooks fails the release process is aborted.
## Complex commands
If you need to do anything more complex, it is recommended to create a shell script and call it instead.
You can also go crazy with `sh -c "my commands"`, but it gets ugly really fast.
If you need to do anything more complex, it is recommended to create a shell
script and call it instead. You can also go crazy with `sh -c "my commands"`,
but it gets ugly really fast.
!!! tip
Learn more about the [name template engine](/customization/templates/).

3
www/docs/customization/includes.md
View File

@@ -3,7 +3,8 @@
!!! success "GoReleaser Pro"
Includes is a [GoReleaser Pro feature](/pro/).
GoReleaser allows you to include other files from an URL or in the current filesystem.
GoReleaser allows you to include other files from an URL or in the current
file system.
Files are included recursively in the order they are declared.

13
www/docs/customization/index.md
View File

@@ -2,13 +2,17 @@
GoReleaser can be customized by tweaking a `.goreleaser.yaml` file.
You can generate an example config by running [`goreleaser init`](/cmd/goreleaser_init/) or start from scratch.
You can generate an example config by running
[`goreleaser init`](/cmd/goreleaser_init/) or start from scratch.
You can also check if your config is valid by running [`goreleaser check`](/cmd/goreleaser_check/), which will tell you if are using deprecated or invalid options.
You can also check if your config is valid by running
[`goreleaser check`](/cmd/goreleaser_check/), which will tell you if are using
deprecated or invalid options.
## JSON Schema
GoReleaser also has a [jsonschema][] file which you can use to have better editor support:
GoReleaser also has a [jsonschema][] file, which you can use to have better
editor support:
=== "OSS"
```sh
@@ -32,7 +36,8 @@ GoReleaser also has a [jsonschema][] file which you can use to have better edito
# yaml-language-server: $schema=https://goreleaser.com/static/schema-pro.json
```
You can also generate it for your specific version using the [`goreleaser jsonschema`][schema] command.
You can also generate it for your specific version using the
[`goreleaser jsonschema`][schema] command.
[jsonschema]: http://json-schema.org/draft/2020-12/json-schema-validation.html
[schema]: /cmd/goreleaser_jsonschema/

27
www/docs/customization/krew.md
View File

@@ -1,6 +1,7 @@
# Krew Plugin Manifests
After releasing to GitHub or GitLab, GoReleaser can generate and publish a _Krew Plugin Manifest_ into a repository that you have access to.
After releasing to GitHub or GitLab, GoReleaser can generate and publish a _Krew
Plugin Manifest_ into a repository that you have access to.
Check their [website](https://krew.sigs.k8s.io) for more information.
@@ -20,18 +21,20 @@ krews:
- foo
- bar
# GOARM to specify which 32-bit arm version to use if there are multiple versions
# from the build section. Krew plugin supports at this moment only one 32-bit version.
# GOARM to specify which 32-bit arm version to use if there are multiple
# versions from the build section. Krew plugin supports at this moment only
# one 32-bit version.
# Default is 6 for all artifacts or each id if there a multiple versions.
goarm: 6
# GOAMD64 to specify which amd64 version to use if there are multiple versions
# from the build section.
# GOAMD64 to specify which amd64 version to use if there are multiple
# versions from the build section.
# Default is v1.
goamd64: v3
# NOTE: make sure the url_template, the token and given repo (github or gitlab) owner and name are from the
# same kind. We will probably unify this in the next major version like it is done with scoop.
# NOTE: make sure the url_template, the token and given repo (github or
# gitlab) owner and name are from the same kind. We will probably unify this
# in the next major version like it is done with scoop.
# GitHub/GitLab repository to push the Krew plugin to
# Gitea is not supported yet, but the support coming
@@ -43,10 +46,12 @@ krews:
# Defaults to the default repository branch.
branch: main
# Optionally a token can be provided, if it differs from the token provided to GoReleaser
# Optionally a token can be provided, if it differs from the token
# provided to GoReleaser
token: "{{ .Env.HOMEBREW_TAP_GITHUB_TOKEN }}"
# Template for the url which is determined by the given Token (github or gitlab)
# Template for the url which is determined by the given Token (github or
# gitlab)
# Default for github is "https://github.com/<repo_owner>/<repo_name>/releases/download/{{ .Tag }}/{{ .ArtifactName }}"
# Default for gitlab is "https://gitlab.com/<repo_owner>/<repo_name>/-/releases/{{ .Tag }}/downloads/{{ .ArtifactName }}"
# Default for gitea is "https://gitea.com/<repo_owner>/<repo_name>/releases/download/{{ .Tag }}/{{ .ArtifactName }}"
@@ -84,8 +89,8 @@ krews:
caveats: "How to use this binary"
# Setting this will prevent goreleaser to actually try to commit the updated
# krew plugin - instead, the plugin file will be stored on the dist folder only,
# leaving the responsibility of publishing it to the user.
# krew plugin - instead, the plugin file will be stored on the dist folder
# only, leaving the responsibility of publishing it to the user.
# If set to auto, the release will not be uploaded to the Krew plugin
# in case there is an indicator for prerelease in the tag e.g. v1.0.0-rc1
# Default is false.

3
www/docs/customization/milestone.md
View File

@@ -1,6 +1,7 @@
# Closing Milestones
GoReleaser can close repository milestones after successfully publishing all artifacts.
GoReleaser can close repository milestones after successfully publishing all
artifacts.
Let's see what can be customized in the `milestones` section:

18
www/docs/customization/monorepo.md
View File

@@ -3,7 +3,8 @@
!!! success "GoReleaser Pro"
The monorepo support is a [GoReleaser Pro feature](/pro/).
If you want to use GoReleaser within a monorepo and use tag prefixes to mark "which tags belong to which sub project", GoReleaser has you covered.
If you want to use GoReleaser within a monorepo and use tag prefixes to mark
"which tags belong to which sub project", GoReleaser has you covered.
## Premises
@@ -17,7 +18,8 @@ You project falls into either one of these categories:
### Category 1
You'll need to create a `.goreleaser.yaml` for each subproject you want to use GoReleaser in:
You'll need to create a `.goreleaser.yaml` for each subproject you want to use
GoReleaser in:
```yaml
# subroj1/.goreleaser.yaml
@@ -36,13 +38,17 @@ goreleaser release --rm-dist -f ./subproj1/.goreleaser.yaml
Then, the following is different from a "regular" run:
- GoReleaser will then look if current commit has a tag prefixed with `subproject1`, and the previous tag with the same prefix;
- Changelog will include only commits that contain changes to files within the `subproj1` directory;
- GoReleaser will then look if current commit has a tag prefixed with
`subproject1`, and the previous tag with the same prefix;
- Changelog will include only commits that contain changes to files within the
`subproj1` directory;
- Release name gets prefixed with `{{ .ProjectName }} ` if empty;
- All build's `dir` setting get set to `monorepo.dir` if empty;
- if yours is not, you might want to change that manually;
- Extra files on the release, archives, Docker builds, etc are prefixed with `monorepo.dir`;
- On templates, `{{.PrefixedTag}}` will be `monorepo.prefix/tag` (aka the actual tag name), and `{{.Tag}}` has the prefix stripped;
- Extra files on the release, archives, Docker builds, etc are prefixed with
`monorepo.dir`;
- On templates, `{{.PrefixedTag}}` will be `monorepo.prefix/tag` (aka the actual
tag name), and `{{.Tag}}` has the prefix stripped;
The rest of the release process should work as usual.

41
www/docs/customization/nfpm.md
View File

@@ -111,7 +111,8 @@ nfpms:
# Version Metadata (previously deb.metadata).
# Default is extracted from `version` if it is semver compatible.
# Setting metadata might interfere with version comparisons depending on the packager.
# Setting metadata might interfere with version comparisons depending on the
# packager.
version_metadata: git
# Version Release.
@@ -123,7 +124,8 @@ nfpms:
# Priority.
priority: extra
# Makes a meta package - an empty package that contains only supporting files and dependencies.
# Makes a meta package - an empty package that contains only supporting
# files and dependencies.
# When set to `true`, the `builds` option is ignored.
# Defaults to false.
meta: true
@@ -158,7 +160,8 @@ nfpms:
dst: /usr/local/bin/foo
type: "symlink"
# Corresponds to `%config(noreplace)` if the packager is rpm, otherwise it is just a config file
# Corresponds to `%config(noreplace)` if the packager is rpm, otherwise it
# is just a config file
- src: path/to/local/bar.conf
dst: /etc/bar.conf
type: "config|noreplace"
@@ -171,8 +174,8 @@ nfpms:
# are added to the package header. From the RPM directives documentation:
#
# "There are times when a file should be owned by the package but not
# installed - log files and state files are good examples of cases you might
# desire this to happen."
# installed - log files and state files are good examples of cases you
# might desire this to happen."
#
# "The way to achieve this, is to use the %ghost directive. By adding this
# directive to the line containing a file, RPM will know about the ghosted
@@ -184,7 +187,8 @@ nfpms:
- dst: /var/log/boo.log
type: ghost
# You can use the packager field to add files that are unique to a specific packager
# You can use the packager field to add files that are unique to a
# specific packager
- src: path/to/rpm/file.conf
dst: /etc/file.conf
type: "config|noreplace"
@@ -198,8 +202,9 @@ nfpms:
type: "config|noreplace"
packager: apk
# Sometimes it is important to be able to set the mtime, mode, owner, or group for a file
# that differs from what is on the local build system at build time.
# Sometimes it is important to be able to set the mtime, mode, owner, or
# group for a file that differs from what is on the local build system at
# build time.
- src: path/to/foo
dst: /usr/local/foo
file_info:
@@ -208,13 +213,15 @@ nfpms:
owner: notRoot
group: notRoot
# Using the type 'dir', empty directories can be created. When building RPMs, however, this
# type has another important purpose: Claiming ownership of that folder. This is important
# because when upgrading or removing an RPM package, only the directories for which it has
# claimed ownership are removed. However, you should not claim ownership of a folder that
# is created by the distro or a dependency of your package.
# A directory in the build environment can optionally be provided in the 'src' field in
# order copy mtime and mode from that directory without having to specify it manually.
# Using the type 'dir', empty directories can be created. When building
# RPMs, however, this type has another important purpose: Claiming
# ownership of that folder. This is important because when upgrading or
# removing an RPM package, only the directories for which it has claimed
# ownership are removed. However, you should not claim ownership of a folder
# thatis created by the distro or a dependency of your package.
# A directory in the build environment can optionally be provided in the
# 'src' field in order copy mtime and mode from that directory without
# having to specify it manually.
- dst: /some/dir
type: dir
file_info:
@@ -284,8 +291,8 @@ nfpms:
# are added to the package header. From the RPM directives documentation:
#
# "There are times when a file should be owned by the package but not
# installed - log files and state files are good examples of cases you might
# desire this to happen."
# installed - log files and state files are good examples of cases you
# might desire this to happen."
#
# "The way to achieve this, is to use the %ghost directive. By adding this
# directive to the line containing a file, RPM will know about the ghosted

20
www/docs/customization/nightlies.md
View File

@@ -3,7 +3,8 @@
!!! success "GoReleaser Pro"
The nightly build feature is a [GoReleaser Pro feature](/pro/).
Whether if you need beta builds or a rolling-release system, the nightly builds feature will do it for you.
Whether if you need beta builds or a rolling-release system, the nightly builds
feature will do it for you.
To enable it, you must use the `--nightly` flag in the [`goreleaser release` command](/cmd/goreleaser_release/).
@@ -14,7 +15,8 @@ You also have some customization options available:
nightly:
# Allows you to change the version of the generated nightly release.
#
# Note that some pipes require this to be semantic version compliant (nfpm, for example).
# Note that some pipes require this to be semantic version compliant (nfpm,
# for example).
#
# Default is `{{ incpatch .Version }}-{{ .ShortCommit }}-nightly`.
name_template: '{{ incpatch .Version }}-devel'
@@ -30,7 +32,8 @@ nightly:
# Default is `false`.
publish_release: true
# Whether to delete previous pre-releases for the same `tag_name` when releasing.
# Whether to delete previous pre-releases for the same `tag_name` when
# releasing.
# This allows you to keep a single pre-release.
#
# Default is `false`.
@@ -39,8 +42,9 @@ nightly:
## How it works
When you run GoReleaser with `--nightly`, it will set the `Version` template variable to the evaluation of `nightly.name_template`.
This means that if you use `{{ .Version }}` on your name templates, you'll get the nightly version.
When you run GoReleaser with `--nightly`, it will set the `Version` template
variable to the evaluation of `nightly.name_template`. This means that if you
use `{{ .Version }}` on your name templates, you'll get the nightly version.
!!! tip
Learn more about the [name template engine](/customization/templates/).
@@ -65,5 +69,7 @@ You can also check if it is a nightly build inside a template with:
```
!!! info "Maybe you are looking for something else?"
- If just want to build the binaries, and no packages at all, check the [`goreleaser build` command](/cmd/goreleaser_build/);
- If you actually want to create a local "snapshot" build, check out the [snapshots documentation](/customization/snapshots/).
- If just want to build the binaries, and no packages at all, check the
[`goreleaser build` command](/cmd/goreleaser_build/);
- If you actually want to create a local "snapshot" build, check out the
[snapshots documentation](/customization/snapshots/).

14
www/docs/customization/publishers.md
View File

@@ -70,7 +70,14 @@ publishers:
- TOKEN={{ .Env.CUSTOM_PUBLISHER_TOKEN }}
```
so the above example will execute `custom-publisher -product=goreleaser -version=1.0.0 goreleaser_1.0.0_linux_amd64.zip` in `/path/to/dist` with `TOKEN=token`, assuming that GoReleaser is executed with `CUSTOM_PUBLISHER_TOKEN=token`.
so the above example will execute:
```bash
custom-publisher -product=goreleaser -version=1.0.0 goreleaser_1.0.0_linux_amd64.zip
```
in `/path/to/dist` with
`TOKEN=token`, assuming that GoReleaser is executed with
`CUSTOM_PUBLISHER_TOKEN=token`.
Supported variables:
@@ -129,8 +136,9 @@ publishers:
name_template: file.txt # note that this only works if glob matches 1 file only
```
These settings should allow you to push your artifacts to any number of endpoints,
which may require non-trivial authentication or has otherwise complex requirements.
These settings should allow you to push your artifacts to any number of
endpoints, which may require non-trivial authentication or has otherwise complex
requirements.
!!! tip
Learn more about the [name template engine](/customization/templates/).

53
www/docs/customization/release.md
View File

@@ -1,7 +1,7 @@
# Release
GoReleaser can create a GitHub/GitLab/Gitea release with the current tag, upload all
the artifacts and generate the changelog based on the new commits since the
GoReleaser can create a GitHub/GitLab/Gitea release with the current tag, upload
all the artifacts and generate the changelog based on the new commits since the
previous tag.
## GitHub
@@ -28,7 +28,8 @@ release:
# Default is false.
draft: true
# Whether to remove existing draft releases with the same name before creating a new one.
# Whether to remove existing draft releases with the same name before creating
# a new one.
# Only effective if `draft` is set to true.
# Available only for GitHub.
#
@@ -38,7 +39,8 @@ release:
# Useful if you want to delay the creation of the tag in the remote.
# You can create the tag locally, but not push it, and run GoReleaser.
# It'll then set the `target_commitish` portion of the GitHub release to the value of this field.
# It'll then set the `target_commitish` portion of the GitHub release to the
# value of this field.
# Only works on GitHub.
#
# Default: empty.
@@ -89,13 +91,15 @@ release:
name_template: "{{.ProjectName}}-v{{.Version}} {{.Env.USER}}"
# You can disable this pipe in order to not create the release on any SCM.
# Keep in mind that this might also break things that depend on the release URL, for instance, homebrew taps.
# Keep in mind that this might also break things that depend on the release
# URL, for instance, homebrew taps.
#
# Defaults to false.
disable: true
# Set this to true if you want to disable just the artifact upload to the SCM.
# If this is true, GoReleaser will still create the release with the changelog, but won't upload anything to it.
# If this is true, GoReleaser will still create the release with the
# changelog, but won't upload anything to it.
#
# Default: false.
# Since: v1.11.
@@ -125,7 +129,8 @@ Let's see what can be customized in the `release` section for GitLab.
```yaml
# .goreleaser.yaml
release:
# Default is extracted from the origin remote URL or empty if its private hosted.
# Default is extracted from the origin remote URL or empty if its private
# hosted.
# You can also use Gitlab's internal project id by setting it in the name
# field and leaving the owner field empty.
gitlab:
@@ -175,7 +180,8 @@ release:
[Learn how to set up an API token, self-hosted GitLab, etc](/scm/gitlab/).
!!! tip
If you use GitLab subgroups, you need to specify it in the `owner` field, e.g. `mygroup/mysubgroup`.
If you use GitLab subgroups, you need to specify it in the `owner` field,
e.g. `mygroup/mysubgroup`.
!!! warning
Only GitLab `v12.9+` is supported for releases.
@@ -231,7 +237,8 @@ release:
name_template: file.txt # note that this only works if glob matches 1 file only
```
To enable uploading `tar.gz` and `checksums.txt` files you need to add the following to your Gitea config in `app.ini`:
To enable uploading `tar.gz` and `checksums.txt` files you need to add the
following to your Gitea config in `app.ini`:
```ini
[attachment]
@@ -246,7 +253,7 @@ ALLOWED_TYPES = application/gzip|application/x-gzip|application/x-gtar|applicati
!!! warning
Gitea versions earlier than 1.9.2 do not support uploading `checksums.txt`
files because of a [bug](https://github.com/go-gitea/gitea/issues/7882)
files because of a [bug](https://github.com/go-gitea/gitea/issues/7882),
so you will have to enable all file types with `*/*`.
!!! warning
@@ -254,21 +261,21 @@ ALLOWED_TYPES = application/gzip|application/x-gzip|application/x-gtar|applicati
### Define Previous Tag
GoReleaser uses `git describe` to get the previous tag used for generating the Changelog.
You can set a different build tag using the environment variable `GORELEASER_PREVIOUS_TAG`.
This is useful in scenarios where two tags point to the same commit.
GoReleaser uses `git describe` to get the previous tag used for generating the
Changelog. You can set a different build tag using the environment variable
`GORELEASER_PREVIOUS_TAG`. This is useful in scenarios where two tags point to
the same commit.
## Custom release notes
You can specify a file containing your custom release notes, and
pass it with the `--release-notes=FILE` flag.
GoReleaser will then skip its own release notes generation,
using the contents of your file instead.
You can use Markdown to format the contents of your file.
You can specify a file containing your custom release notes, and pass it with
the `--release-notes=FILE` flag. GoReleaser will then skip its own release notes
generation, using the contents of your file instead. You can use Markdown to
format the contents of your file.
On Unix systems you can also generate the release notes in-line by using
[process substitution](https://en.wikipedia.org/wiki/Process_substitution).
To list all commits since the last tag, but skip ones starting with `Merge` or
[process substitution](https://en.wikipedia.org/wiki/Process_substitution). To
list all commits since the last tag, but skip ones starting with `Merge` or
`docs`, you could run this command:
```sh
@@ -281,6 +288,6 @@ Some changelog generators you can use:
- [miniscruff/changie](https://github.com/miniscruff/changie)
!!! info
If you create the release before running GoReleaser, and the
said release has some text in its body, GoReleaser will not override it with
its release notes.
If you create the release before running GoReleaser, and the said release
has some text in its body, GoReleaser will not override it with its release
notes.

44
www/docs/customization/sbom.md
View File

@@ -2,17 +2,19 @@
Since: v1.2.
A Software Bill of Materials (SBOM) is a description of the components that make up a software artifact.
A Software Bill of Materials (SBOM) is a description of the components that make
up a software artifact.
Goreleaser can create one or more SBOMs for any artifacts generated by Goreleaser.
Goreleaser can create one or more SBOMs for any artifacts generated by
Goreleaser.
## Usage
The artifact cataloging step can analyze one or more artifacts generated by Goreleaser and output one or more
SBOM files into the dist directory.
The artifact cataloging step can analyze one or more artifacts generated by
Goreleaser and output one or more SBOM files into the dist directory.
The default is configured to create an SBOM for each binary produced with [Syft](https://github.com/anchore/syft).
To enable artifact cataloging just add:
The default is configured to create an SBOM for each binary produced with
[Syft](https://github.com/anchore/syft). To enable artifact cataloging just add:
```yaml
# .goreleaser.yml
@@ -31,7 +33,8 @@ sboms:
# Defaults to "default".
id: foo
# List of Names/templates of the SBOM documents created at this step (relative to the dist dir).
# List of Names/templates of the SBOM documents created at this step
# (relative to the dist dir).
#
# Each element configured is made available as variables. For example:
# documents: ["foo", "bar"]
@@ -45,7 +48,8 @@ sboms:
# - "any": []
# - otherwise: ["{{ .ArtifactName }}.sbom"]
#
# Note that multiple sbom values are only allowed if the value of "artifacts" is "any".
# Note that multiple sbom values are only allowed if the value of
# "artifacts" is "any".
documents:
- "${artifact}.spdx.sbom"
@@ -61,7 +65,8 @@ sboms:
# Defaults to `["$artifact", "--file", "$document", "--output", "spdx-json"]`
args: ["$artifact", "--file", "$sbom", "--output", "spdx-json"]
# List of environment variables that will be passed to the SBOM command as well as the templates.
# List of environment variables that will be passed to the SBOM command as
# well as the templates.
#
# Defaults to [ "SYFT_FILE_METADATA_CATALOGER_ENABLED=true" ]
env:
@@ -70,7 +75,8 @@ sboms:
# Which artifacts to catalog
#
# any: let the SBOM tool decide what artifacts available in the cwd should be cataloged
# any: let the SBOM tool decide what artifacts available in the cwd
# should be cataloged
# source: source archive
# package: linux packages (deb, rpm, apk)
# archive: archives from archive pipe
@@ -91,14 +97,20 @@ sboms:
### Available variable names
These environment variables might be available in the fields that are templateable:
These environment variables might be available in the fields that are
templateable:
- `${artifact}`: the path to the artifact that will be cataloged (unless "artifacts" config item is "any")
- `${artifactID}`: the ID of the artifact that will be cataloged (unless "artifacts" config item is "any")
- `${document}`: the SBOM filename generated (corresponds to `${document0}` if the "artifacts" config item is "any")
- `${document#}`: the SBOM filenames generated, where `#` corresponds to the list index under the "documents" config item (e.g. `${document0}`)
- `${artifact}`: the path to the artifact that will be cataloged (unless
"artifacts" config item is "any")
- `${artifactID}`: the ID of the artifact that will be cataloged (unless
"artifacts" config item is "any")
- `${document}`: the SBOM filename generated (corresponds to `${document0}` if
the "artifacts" config item is "any")
- `${document#}`: the SBOM filenames generated, where `#` corresponds to the
list index under the "documents" config item (e.g. `${document0}`)
## Limitations
Container images generated by Goreleaser are not available to be cataloged by the SBOM tool.
Container images generated by Goreleaser are not available to be cataloged by
the SBOM tool.

9
www/docs/customization/scoop.md
View File

@@ -3,8 +3,8 @@
After releasing to GitHub or GitLab, GoReleaser can generate and publish a
_Scoop App Manifest_ into a repository that you have access to.
The `scoop` section specifies how the manifest should be created. See
the commented example below:
The `scoop` section specifies how the manifest should be created. See the
commented example below:
```yaml
# .goreleaser.yaml
@@ -24,7 +24,8 @@ scoop:
# Defaults to the default repository branch.
branch: main
# Optionally a token can be provided, if it differs from the token provided to GoReleaser
# Optionally a token can be provided, if it differs from the token provided
# to GoReleaser
token: "{{ .Env.SCOOP_TAP_GITHUB_TOKEN }}"
# Folder inside the repository to put the scoop.
@@ -79,7 +80,7 @@ scoop:
```
By defining the `scoop` section, GoReleaser will take care of publishing the
Scoop app. Assuming that the project name is `drumroll` and the current tag is
Scoop app. Assuming that the project name is `drumroll`, and the current tag is
`v1.2.3`, the above configuration will generate a `drumroll.json` manifest in
the root of the repository specified in the `bucket` section.

39
www/docs/customization/sign.md
View File

@@ -1,6 +1,6 @@
# Signing checksums and artifacts
Signing ensures that the artifacts have been generated by yourself and your
Signing ensures that the artifacts have been generated by yourself, and your
users can verify that by comparing the generated signature with your public
signing key.
@@ -8,11 +8,11 @@ GoReleaser provides means to sign both executables and archives.
## Usage
Signing works in combination with checksum files and it is generally sufficient
Signing works in combination with checksum files, and it is generally enough
to sign the checksum files only.
The default is configured to create a detached signature for the checksum files
with [GnuPG](https://www.gnupg.org/) and your default key. To enable signing
with [GnuPG](https://www.gnupg.org/), and your default key. To enable signing
just add
```yaml
@@ -98,7 +98,8 @@ signs:
- FOO=bar
- HONK=honkhonk
# By default, the stdout and stderr of the signing cmd are discarded unless GoReleaser is running with `--debug` set.
# By default, the stdout and stderr of the signing cmd are discarded unless
# GoReleaser is running with `--debug` set.
# You can set this to true if you want them to be displayed regardless.
#
# Default: false.
@@ -108,7 +109,8 @@ signs:
### Available variable names
These environment variables might be available in the fields that are templateable:
These environment variables might be available in the fields that are
templateable:
- `${artifact}`: the path to the artifact that will be signed
- `${artifactID}`: the ID of the artifact that will be signed
@@ -117,9 +119,10 @@ These environment variables might be available in the fields that are templateab
## Signing with cosign
You can sign you artifacts with [cosign][] as well.
You can sign your artifacts with [cosign][] as well.
Assuming you have a `cosign.key` in the repository root and a `COSIGN_PWD` environment variable set, a simple usage example would look like this:
Assuming you have a `cosign.key` in the repository root and a `COSIGN_PWD`
environment variable set, a simple usage example would look like this:
```yaml
# .goreleaser.yaml
@@ -144,7 +147,7 @@ Executables can be signed after build using post hooks.
### With gon
For example, you can use [gon][] to create notarized MacOS apps:
For example, you can use [gon][] to create notarized macOS apps:
```yaml
# .goreleaser.yaml
@@ -188,21 +191,24 @@ sign {
}
```
Note that notarizing may take some time, and will need to be run from a MacOS machine.
Note that notarizing may take some time, and will need to be run from a macOS
machine.
If you generate ZIP or DMG as part of your signing via gon you may need
to ensure their file names align with desired pattern of other artifacts
as GoReleaser doesn't control how these get generated beyond just executing `gon`
If you generate ZIP or DMG as part of your signing via gon you may need to
ensure their file names align with desired pattern of other artifacts as
GoReleaser doesn't control how these get generated beyond just executing `gon`
with given arguments. Relatedly you may need to list these additional artifacts
as `extra_files` in the `release` section to make sure they also get uploaded.
You can also check [this issue](https://github.com/goreleaser/goreleaser/issues/1227) for more details.
You can also check
[this issue](https://github.com/goreleaser/goreleaser/issues/1227) for more
details.
### With cosign
You can also use [cosign][] to sign the binaries directly,
but you'll need to manually add the `.sig` files to the release and/or archive:
You can also use [cosign][] to sign the binaries directly, but you'll need to
manually add the `.sig` files to the release and/or archive:
```yaml
# .goreleaser.yaml
@@ -230,7 +236,8 @@ Please refer to [Docker Images Signing](/customization/docker_sign/).
## Limitations
You can sign with any command that either outputs a file or modify the file being signed.
You can sign with any command that either outputs a file or modify the file
being signed.
If you want to sign with something that writes to `STDOUT` instead of a file,
you can wrap the command inside a `sh -c` execution, for instance:

15
www/docs/customization/snapcraft.md
View File

@@ -69,10 +69,10 @@ snapcrafts:
- beta
- candidate
- stable
- {{ .Major }}.{{ .Minor }}/edge
- {{ .Major }}.{{ .Minor }}/beta
- {{ .Major }}.{{ .Minor }}/candidate
- {{ .Major }}.{{ .Minor }}/stable
- '{{ .Major }}.{{ .Minor }}/edge'
- '{{ .Major }}.{{ .Minor }}/beta'
- '{{ .Major }}.{{ .Minor }}/candidate'
- '{{ .Major }}.{{ .Minor }}/stable'
# A guardrail to prevent you from releasing a snap to all your users before
# it is ready.
@@ -89,7 +89,8 @@ snapcrafts:
# https://snapcraft.io/docs/reference/confinement
confinement: strict
# Your app's license, based on SPDX license expressions: https://spdx.org/licenses
# Your app's license, based on SPDX license expressions:
# https://spdx.org/licenses
# Default is empty.
license: MIT
@@ -112,8 +113,8 @@ snapcrafts:
mode: 0755
# With layouts, you can make elements in $SNAP, $SNAP_DATA, $SNAP_COMMON
# accessible from locations such as /usr, /var and /etc. This helps when using
# pre-compiled binaries and libraries that expect to find files and
# accessible from locations such as /usr, /var and /etc. This helps when
# using pre-compiled binaries and libraries that expect to find files and
# directories outside of locations referenced by $SNAP or $SNAP_DATA.
# About snap environment variables:
# * HOME: set to SNAP_USER_DATA for all commands

16
www/docs/customization/snapshots.md
View File

@@ -3,8 +3,8 @@
Sometimes we want to generate a full build of our project,
but neither want to validate anything nor upload it to anywhere.
GoReleaser supports this with the `--snapshot` flag
and also with the `snapshot` customization section:
GoReleaser supports this with the `--snapshot` flag and with the `snapshot`
customization section:
```yaml
# .goreleaser.yaml
@@ -20,10 +20,11 @@ snapshot:
## How it works
When you run GoReleaser with `--snapshot`, it will set the `Version` template variable to the evaluation of `snapshot.name_template`.
This means that if you use `{{ .Version }}` on your name templates, you'll get the snapshot version.
When you run GoReleaser with `--snapshot`, it will set the `Version` template
variable to the evaluation of `snapshot.name_template`. This means that if you
use `{{ .Version }}` on your name templates, you'll get the snapshot version.
You can also check if its a snapshot build inside a template with:
You can also check if it's a snapshot build inside a template with:
```
{{ if .IsSnapshot }}something{{ else }}something else{{ end }}
@@ -32,8 +33,9 @@ You can also check if its a snapshot build inside a template with:
!!! tip
Learn more about the [name template engine](/customization/templates/).
Note that the idea behind GoReleaser's snapshots is for local builds or to validate your build on the CI pipeline.
Artifacts won't be uploaded and will only be generated into the `dist` folder.
Note that the idea behind GoReleaser's snapshots is for local builds or to
validate your build on the CI pipeline. Artifacts won't be uploaded and will
only be generated into the `dist` folder.
!!! info "Maybe you are looking for something else?"
- If just want to build the binaries, and no packages at all, check the [`goreleaser build` command](/cmd/goreleaser_build/);

4
www/docs/customization/source.md
View File

@@ -1,7 +1,7 @@
# Source Archive
You may add the current tag source archive to the release as well. This is particularly
useful if you want to sign it, for example.
You may add the current tag source archive to the release as well. This is
particularly useful if you want to sign it, for example.
```yaml
# .goreleaser.yaml

170
www/docs/customization/templates.md
View File

@@ -6,107 +6,116 @@ Those fields are often suffixed with `_template`, but sometimes they may not
be. The documentation of each section should be explicit about which fields
support templating.
<!-- to format the tables, use: https://tabletomarkdown.com/format-markdown-table/ -->
## Common Fields
On fields that support templating, these fields are always available:
| Key | Description |
|------------------------|--------------------------------------------------------------------------------------------------------|
| `.ProjectName` | the project name |
| `.Version` | the version being released[^1] |
| `.Branch` | the current git branch |
| `.PrefixedTag` | the current git tag prefixed with the monorepo config tag prefix (if any) |
| `.Tag` | the current git tag |
| `.PrefixedPreviousTag` | the previous git tag prefixed with the monorepo config tag prefix (if any) |
| `.PreviousTag` | the previous git tag, or empty if no previous tags |
| `.ShortCommit` | the git commit short hash |
| `.FullCommit` | the git commit full hash |
| `.Commit` | the git commit hash (deprecated) |
| `.CommitDate` | the UTC commit date in RFC 3339 format |
| `.CommitTimestamp` | the UTC commit date in Unix format |
| `.GitURL` | the git remote url |
| `.Major` | the major part of the version[^2] |
| `.Minor` | the minor part of the version[^2] |
| `.Patch` | the patch part of the version[^2] |
| `.Prerelease` | the prerelease part of the version, e.g. `beta`[^2] |
| `.RawVersion` | composed of `{Major}.{Minor}.{Patch}` [^2] |
| `.ReleaseNotes` | the generated release notes, available after the changelog step has been executed |
| `.IsSnapshot` | `true` if `--snapshot` is set, `false` otherwise |
| `.IsNightly` | `true` if `--nightly` is set, `false` otherwise |
| `.Env` | a map with system's environment variables |
| `.Date` | current UTC date in RFC 3339 format |
| `.Timestamp` | current UTC time in Unix format |
| `.ModulePath` | the go module path, as reported by `go list -m` |
| `incpatch "v1.2.4"` | increments the patch of the given version[^3] |
| `incminor "v1.2.4"` | increments the minor of the given version[^3] |
| `incmajor "v1.2.4"` | increments the major of the given version[^3] |
| `.ReleaseURL` | the current release download url[^4] |
| `.Summary` | the git summary, e.g. `v1.0.0-10-g34f56g3`[^5] |
| `.PrefixedSummary` | the git summary prefixed with the monorepo config tag prefix (if any) |
| `.TagSubject` | the annotated tag message subject, or the message subject of the commit it points out[^6]. Since v1.2. |
| `.TagContents` | the annotated tag message, or the message of the commit it points out[^7]. Since v1.2. |
| `.TagBody` | the annotated tag message's body, or the message's body of the commit it points out[^7]. Since v1.2. |
| `.Runtime.Goos` | equivalent to `runtime.GOOS`. Since v1.5. |
| `.Runtime.Goarch` | equivalent to `runtime.GOARCH`. Since v1.5. |
Key |Description
----------------------|--------------------------------------------------------------------------------------------------------------------
`.ProjectName` |the project name
`.Version` |the version being released[^version-prefix]
`.Branch` |the current git branch
`.PrefixedTag` |the current git tag prefixed with the monorepo config tag prefix (if any)
`.Tag` |the current git tag
`.PrefixedPreviousTag`|the previous git tag prefixed with the monorepo config tag prefix (if any)
`.PreviousTag` |the previous git tag, or empty if no previous tags
`.ShortCommit` |the git commit short hash
`.FullCommit` |the git commit full hash
`.Commit` |the git commit hash (deprecated)
`.CommitDate` |the UTC commit date in RFC 3339 format
`.CommitTimestamp` |the UTC commit date in Unix format
`.GitURL` |the git remote url
`.Major` |the major part of the version[^tag-is-semver]
`.Minor` |the minor part of the version[^tag-is-semver]
`.Patch` |the patch part of the version[^tag-is-semver]
`.Prerelease` |the prerelease part of the version, e.g. `beta`[^tag-is-semver]
`.RawVersion` |composed of `{Major}.{Minor}.{Patch}` [^tag-is-semver]
`.ReleaseNotes` |the generated release notes, available after the changelog step has been executed
`.IsSnapshot` |`true` if `--snapshot` is set, `false` otherwise
`.IsNightly` |`true` if `--nightly` is set, `false` otherwise
`.Env` |a map with system's environment variables
`.Date` |current UTC date in RFC 3339 format
`.Timestamp` |current UTC time in Unix format
`.ModulePath` |the go module path, as reported by `go list -m`
`incpatch "v1.2.4"` |increments the patch of the given version[^panic-if-not-semver]
`incminor "v1.2.4"` |increments the minor of the given version[^panic-if-not-semver]
`incmajor "v1.2.4"` |increments the major of the given version[^panic-if-not-semver]
`.ReleaseURL` |the current release download url[^scm-release-url]
`.Summary` |the git summary, e.g. `v1.0.0-10-g34f56g3`[^git-summary]
`.PrefixedSummary` |the git summary prefixed with the monorepo config tag prefix (if any)
`.TagSubject` |the annotated tag message subject, or the message subject of the commit it points out[^git-tag-subject]. Since v1.2.
`.TagContents` |the annotated tag message, or the message of the commit it points out[^git-tag-body]. Since v1.2.
`.TagBody` |the annotated tag message's body, or the message's body of the commit it points out[^git-tag-body]. Since v1.2.
`.Runtime.Goos` |equivalent to `runtime.GOOS`. Since v1.5.
`.Runtime.Goarch` |equivalent to `runtime.GOARCH`. Since v1.5.
[^1]: The `v` prefix is stripped, and it might be changed in `snapshot` and `nightly` builds.
[^2]: Assuming `Tag` is a valid a SemVer, otherwise empty/zeroed.
[^3]: Will panic if not a semantic version.
[^4]: Composed of the current SCM's download URL and current tag. For instance, on GitHub, it'll be `https://github.com/{owner}/{repo}/releases/tag/{tag}`.
[^5]: It is generated by `git describe --dirty --always --tags`, the format will be `{Tag}-$N-{CommitSHA}`
[^6]: As reported by `git tag -l --format='%(contents:subject)'`
[^7]: As reported by `git tag -l --format='%(contents)'`
[^version-prefix]: The `v` prefix is stripped, and it might be changed in
`snapshot` and `nightly` builds.
[^tag-is-semver]: Assuming `Tag` is a valid a SemVer, otherwise empty/zeroed.
[^panic-if-not-semver]: Will panic if not a semantic version.
[^scm-release-url]: Composed of the current SCM's download URL and current tag.
For instance, on GitHub, it'll be
`https://github.com/{owner}/{repo}/releases/tag/{tag}`.
[^git-summary]: It is generated by `git describe --dirty --always --tags`, the
format will be `{Tag}-$N-{CommitSHA}`
[^git-tag-subject]: As reported by `git tag -l --format='%(contents:subject)'`
[^git-tag-body]: As reported by `git tag -l --format='%(contents)'`
## Single-artifact extra fields
On fields that are related to a single artifact (e.g., the binary name), you
may have some extra fields:
| Key | Description |
|-----------------|----------------------------------------------|
| `.Os` | `GOOS`[^8] |
| `.Arch` | `GOARCH`[^8] |
| `.Arm` | `GOARM`[^8] |
| `.Mips` | `GOMIPS`[^8] |
| `.Amd64` | `GOAMD64`[^8] |
| `.Binary` | binary name |
| `.ArtifactName` | archive name |
| `.ArtifactPath` | absolute path to artifact |
| `.ArtifactExt` | binary extension (e.g. `.exe`). Since v1.11. |
Key |Description
---------------|--------------------------------------------
`.Os` |`GOOS`[^archive-replacementes]
`.Arch` |`GOARCH`[^archive-replacementes]
`.Arm` |`GOARM`[^archive-replacementes]
`.Mips` |`GOMIPS`[^archive-replacementes]
`.Amd64` |`GOAMD64`[^archive-replacementes]
`.Binary` |binary name
`.ArtifactName`|archive name
`.ArtifactPath`|absolute path to artifact
`.ArtifactExt` |binary extension (e.g. `.exe`). Since v1.11.
[^8]: Might have been replaced by `archives.replacements`.
[^archive-replacementes]: Might have been replaced by `archives.replacements`.
## nFPM extra fields
On the nFPM name template field, you can use those extra fields as well:
| Key | Description |
|----------------|-----------------------------------------------------------------|
| `.Release` | release from the nfpm config |
| `.Epoch` | epoch from the nfpm config |
| `.PackageName` | package the name. Same as `ProjectName` if not overridden. |
| `.ConventionalFileName` | conventional package file name as provided by nFPM[^9] |
Key |Description
-----------------------|--------------------------------------------------------------
`.Release` |release from the nfpm config
`.Epoch` |epoch from the nfpm config
`.PackageName` |package the name. Same as `ProjectName` if not overridden.
`.ConventionalFileName`|conventional package file name as provided by nFPM[^arm-names]
[^9]: Please beware: some OSs might have the same names for different ARM versions, for example, for Debian both ARMv6 and ARMv7 are called `armhf`. Make sure that's not your case otherwise you might end up with colliding names. It also does not handle multiple GOAMD64 versions.
[^arm-names]: Please beware: some OSs might have the same names for different
ARM versions, for example, for Debian both ARMv6 and ARMv7 are called `armhf`.
Make sure that's not your case otherwise you might end up with colliding
names. It also does not handle multiple GOAMD64 versions.
## Functions
On all fields, you have these available functions:
| Usage | Description |
|--------------------------------|--------------------------------------------------------------------------------------------------------------------------------|
| `replace "v1.2" "v" ""` | replaces all matches. See [ReplaceAll](https://golang.org/pkg/strings/#ReplaceAll) |
| `split "1.2" "."` | split string at separator. See [Split](https://golang.org/pkg/strings/#Split). Since v1.11. |
| `time "01/02/2006"` | current UTC time in the specified format (this is not deterministic, a new time for every call) |
| `tolower "V1.2"` | makes input string lowercase. See [ToLower](https://golang.org/pkg/strings/#ToLower) |
| `toupper "v1.2"` | makes input string uppercase. See [ToUpper](https://golang.org/pkg/strings/#ToUpper) |
| `trim " v1.2 "` | removes all leading and trailing white space. See [TrimSpace](https://golang.org/pkg/strings/#TrimSpace) |
| `trimprefix "v1.2" "v"` | removes provided leading prefix string, if present. See [TrimPrefix](https://golang.org/pkg/strings/#TrimPrefix) |
| `trimsuffix "1.2v" "v"` | removes provided trailing suffix string, if present. See [TrimSuffix](https://pkg.go.dev/strings#TrimSuffix) |
| `dir .Path` | returns all but the last element of path, typically the path's directory. See [Dir](https://golang.org/pkg/path/filepath/#Dir) |
| `abs .ArtifactPath` | returns an absolute representation of path. See [Abs](https://golang.org/pkg/path/filepath/#Abs) |
| `filter "text" "regex"` | keeps only the lines matching the given regex, analogous to `grep -E`. Since v1.6. |
| `reverseFilter "text" "regex"` | keeps only the lines **not** matching the given regex, analogous to `grep -vE`. Since v1.6. |
Usage |Description
------------------------------|------------------------------------------------------------------------------------------------------------------------------
`replace "v1.2" "v" ""` |replaces all matches. See [ReplaceAll](https://golang.org/pkg/strings/#ReplaceAll)
`split "1.2" "."` |split string at separator. See [Split](https://golang.org/pkg/strings/#Split). Since v1.11.
`time "01/02/2006"` |current UTC time in the specified format (this is not deterministic, a new time for every call)
`tolower "V1.2"` |makes input string lowercase. See [ToLower](https://golang.org/pkg/strings/#ToLower)
`toupper "v1.2"` |makes input string uppercase. See [ToUpper](https://golang.org/pkg/strings/#ToUpper)
`trim " v1.2 "` |removes all leading and trailing white space. See [TrimSpace](https://golang.org/pkg/strings/#TrimSpace)
`trimprefix "v1.2" "v"` |removes provided leading prefix string, if present. See [TrimPrefix](https://golang.org/pkg/strings/#TrimPrefix)
`trimsuffix "1.2v" "v"` |removes provided trailing suffix string, if present. See [TrimSuffix](https://pkg.go.dev/strings#TrimSuffix)
`dir .Path` |returns all but the last element of path, typically the path's directory. See [Dir](https://golang.org/pkg/path/filepath/#Dir)
`abs .ArtifactPath` |returns an absolute representation of path. See [Abs](https://golang.org/pkg/path/filepath/#Abs)
`filter "text" "regex"` |keeps only the lines matching the given regex, analogous to `grep -E`. Since v1.6.
`reverseFilter "text" "regex"`|keeps only the lines **not** matching the given regex, analogous to `grep -vE`. Since v1.6.
With all those fields, you may be able to compose the name of your artifacts
pretty much the way you want:
@@ -136,8 +145,9 @@ GOVERSION_NR=$(go version | awk '{print $3;}') goreleaser
!!! success "GoReleaser Pro"
Custom template variables support is a [GoReleaser Pro feature](/pro/).
You can also declare custom variables.
This feature is specially useful with [includes](/customization/includes/), so you can have more generic config files.
You can also declare custom variables. This feature is specially useful with
[includes](/customization/includes/), so you can have more generic configuration
files.
Usage is as simple as you would expect:

29
www/docs/customization/universalbinaries.md
View File

@@ -1,7 +1,8 @@
# macOS Universal Binaries
GoReleaser can create _macOS Universal Binaries_ - also known as _Fat Binaries_.
Those binaries are in a special format that contains both `arm64` and `amd64` executables in a single file.
Those binaries are in a special format that contains both `arm64` and `amd64`
executables in a single file.
Here's how to use it:
@@ -30,7 +31,8 @@ universal_binaries:
name_template: '{{.ProjectName}}_{{.Version}}'
# Whether to remove the previous single-arch binaries from the artifact list.
# If left as false, your end release might have both several macOS archives: amd64, arm64 and all.
# If left as false, your end release might have both several macOS archives:
# amd64, arm64 and all.
#
# Defaults to false.
replace: true
@@ -64,7 +66,8 @@ From there, the `Arch` template variable for this file will be `all`.
You can use the Go template engine to remove it if you'd like.
!!! warning
You'll want to change `name_template` for each `id` you add in universal binaries, otherwise they'll have the same name.
You'll want to change `name_template` for each `id` you add in universal
binaries, otherwise they'll have the same name.
Example:
@@ -81,15 +84,17 @@ You can use the Go template engine to remove it if you'd like.
Most fields that support [templating](/customization/templates/) will also
support the following build details:
| Key | Description |
|---------|-----------------------------------|
| .Os | `GOOS`, always `darwin` |
| .Arch | `GOARCH`, always `all` |
| .Arm | `GOARM`, always empty |
| .Ext | Extension, always empty |
| .Target | Build target, always `darwin_all` |
| .Path | The binary path |
| .Name | The binary name |
<!-- to format the tables, use: https://tabletomarkdown.com/format-markdown-table/ -->
Key |Description
-------|---------------------------------
.Os |`GOOS`, always `darwin`
.Arch |`GOARCH`, always `all`
.Arm |`GOARM`, always empty
.Ext |Extension, always empty
.Target|Build target, always `darwin_all`
.Path |The binary path
.Name |The binary name
!!! tip
Notice that `.Path` and `.Name` will only be available after they are

15
www/docs/customization/upload.md
View File

@@ -39,7 +39,8 @@ An example configuration for `goreleaser` in upload mode `binary` with the targe
target: 'http://some.server/some/path/example-repo-local/{{ .ProjectName }}/{{ .Version }}/{{ .Os }}/{{ .Arch }}{{ if .Arm }}{{ .Arm }}{{ end }}'
```
and will result in an HTTP PUT request sent to `http://some.server/some/path/example-repo-local/goreleaser/1.0.0/Darwin/x86_64/goreleaser`.
and will result in an HTTP PUT request sent to
`http://some.server/some/path/example-repo-local/goreleaser/1.0.0/Darwin/x86_64/goreleaser`.
Supported variables:
@@ -96,8 +97,9 @@ This field is optional and is used only for basic http authentication.
### Client authorization with x509 certificate (mTLS / mutual TLS)
If your artifactory server supports authorization with mTLS (client certificates), you can provide them by specifying
the location of an x509 certificate/key pair of pem-encode files.
If your artifactory server supports authorization with mTLS (client
certificates), you can provide them by specifying the location of an x509
certificate/key pair of pem-encode files.
```yaml
uploads:
@@ -112,8 +114,8 @@ and authorize you to upload.
### Server authentication
You can authenticate your TLS server adding a trusted X.509 certificate chain
in your upload configuration.
You can authenticate your TLS server adding a trusted X.509 certificate chain in
your upload configuration.
The trusted certificate chain will be used to validate the server certificates.
@@ -219,7 +221,8 @@ uploads:
-----END CERTIFICATE-----
```
These settings should allow you to push your artifacts into multiple HTTP servers.
These settings should allow you to push your artifacts into multiple HTTP
servers.
!!! tip
Learn more about the [name template engine](/customization/templates/).

19
www/docs/customization/verifiable_builds.md
View File

@@ -1,9 +1,11 @@
# Verifiable Builds
GoReleaser has support for creating verifiable builds.
A [verifiable build][vgo] is one that records enough information to be precise about exactly how to repeat it.
All dependencies are loaded via `proxy.golang.org`, and verified against the checksum database `sum.golang.org`.
A GoReleaser-created verifiable build will include module information in the resulting binary, which can be printed using `go version -m mybinary`.
GoReleaser has support for creating verifiable builds. A [verifiable build][vgo]
is one that records enough information to be precise about exactly how to repeat
it. All dependencies are loaded via `proxy.golang.org`, and verified against the
checksum database `sum.golang.org`. A GoReleaser-created verifiable build will
include module information in the resulting binary, which can be printed using
`go version -m mybinary`.
Configuration options available are described below.
@@ -12,13 +14,15 @@ Configuration options available are described below.
gomod:
# Proxy a module from proxy.golang.org, making the builds verifiable.
# This will only be effective if running against a tag. Snapshots will ignore this setting.
# This will only be effective if running against a tag. Snapshots will ignore
# this setting.
# Notice: for this to work your `build.main` must be a package, not a `.go` file.
#
# Default is false.
proxy: true
# If proxy is true, use these environment variables when running `go mod` commands (namely, `go mod tidy`).
# If proxy is true, use these environment variables when running `go mod`
# commands (namely, `go mod tidy`).
# Defaults to `os.Environ()`.
env:
- GOPROXY=https://proxy.golang.org,direct
@@ -37,6 +41,7 @@ gomod:
```
!!! tip
You can use `debug.ReadBuildInfo()` to get the version/checksum/dependencies of the module.
You can use `debug.ReadBuildInfo()` to get the version/checksum/dependencies
of the module.
[vgo]: https://research.swtch.com/vgo-repro

10
www/docs/errors/dirty.md
View File

@@ -1,9 +1,10 @@
# Git is currently in a dirty state
# Git is in a dirty state
GoReleaser requires a clean git state to work.
If you see this error, it means that something in your build process is either creating or editing files before GoReleaser is called.
The error message should show you which files were created/modified.
If you see this error, it means that something in your build process is either
creating or editing files before GoReleaser is called. The error message should
show you, which files were created/modified.
Here's an example error:
@@ -18,5 +19,6 @@ Learn more at https://goreleaser.com/errors/dirty
From here on, you have a couple of options:
- add the file to `.gitignore` (recommended if the file is temporary and/or generated);
- add the file to `.gitignore` (recommended if the file is temporary and/or
generated);
- change your process the build process to not touch any git tracked files.