diff --git a/internal/pipe/git/errors.go b/internal/pipe/git/errors.go index f85ae85a023..331508ec6c6 100644 --- a/internal/pipe/git/errors.go +++ b/internal/pipe/git/errors.go @@ -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. diff --git a/www/docs/ci/actions.md b/www/docs/ci/actions.md index d72237241bd..625a446d935 100644 --- a/www/docs/ci/actions.md +++ b/www/docs/ci/actions.md @@ -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 + + ### 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/) - -`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: + - `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. + +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 - diff --git a/www/docs/ci/azurepipelines.md b/www/docs/ci/azurepipelines.md index 4f7e612c9e6..6a57fdd8f16 100644 --- a/www/docs/ci/azurepipelines.md +++ b/www/docs/ci/azurepipelines.md @@ -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 | + +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 diff --git a/www/docs/customization/artifactory.md b/www/docs/customization/artifactory.md index 598700920f0..a18462c2a25 100644 --- a/www/docs/customization/artifactory.md +++ b/www/docs/customization/artifactory.md @@ -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 diff --git a/www/docs/customization/aur.md b/www/docs/customization/aur.md index 39ba884929e..eec647dc724 100644 --- a/www/docs/customization/aur.md +++ b/www/docs/customization/aur.md @@ -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. diff --git a/www/docs/customization/blob.md b/www/docs/customization/blob.md index fdb924e7fc9..4f262c57a5d 100644 --- a/www/docs/customization/blob.md +++ b/www/docs/customization/blob.md @@ -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` diff --git a/www/docs/customization/build.md b/www/docs/customization/build.md index 8dc1cf71e24..c2f135597b4 100644 --- a/www/docs/customization/build.md +++ b/www/docs/customization/build.md @@ -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`| + + +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` | + + + +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: diff --git a/www/docs/customization/docker_manifest.md b/www/docs/customization/docker_manifest.md index 353415960b2..fb59b4fd69e 100644 --- a/www/docs/customization/docker_manifest.md +++ b/www/docs/customization/docker_manifest.md @@ -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. diff --git a/www/docs/customization/docker_sign.md b/www/docs/customization/docker_sign.md index bcfcbcd37dc..8e1fc7bbf4e 100644 --- a/www/docs/customization/docker_sign.md +++ b/www/docs/customization/docker_sign.md @@ -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 ``` diff --git a/www/docs/customization/env.md b/www/docs/customization/env.md index 830d4f9651b..d896992fa0e 100644 --- a/www/docs/customization/env.md +++ b/www/docs/customization/env.md @@ -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. diff --git a/www/docs/customization/fury.md b/www/docs/customization/fury.md index 720abf942d0..a52340fcc20 100644 --- a/www/docs/customization/fury.md +++ b/www/docs/customization/fury.md @@ -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 diff --git a/www/docs/customization/homebrew.md b/www/docs/customization/homebrew.md index 74b18c1e227..b76b22c64ab 100644 --- a/www/docs/customization/homebrew.md +++ b/www/docs/customization/homebrew.md @@ -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 diff --git a/www/docs/customization/hooks.md b/www/docs/customization/hooks.md index 26871dedc4a..a1286139bf3 100644 --- a/www/docs/customization/hooks.md +++ b/www/docs/customization/hooks.md @@ -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/). diff --git a/www/docs/customization/includes.md b/www/docs/customization/includes.md index ba740c667a9..9ab22ec1923 100644 --- a/www/docs/customization/includes.md +++ b/www/docs/customization/includes.md @@ -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. diff --git a/www/docs/customization/index.md b/www/docs/customization/index.md index e412d8ad964..3797e830b49 100644 --- a/www/docs/customization/index.md +++ b/www/docs/customization/index.md @@ -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/ diff --git a/www/docs/customization/krew.md b/www/docs/customization/krew.md index 112509e7878..9efe07ac76c 100644 --- a/www/docs/customization/krew.md +++ b/www/docs/customization/krew.md @@ -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///releases/download/{{ .Tag }}/{{ .ArtifactName }}" # Default for gitlab is "https://gitlab.com///-/releases/{{ .Tag }}/downloads/{{ .ArtifactName }}" # Default for gitea is "https://gitea.com///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. diff --git a/www/docs/customization/milestone.md b/www/docs/customization/milestone.md index 76173eaf9ee..0fb992d3e93 100644 --- a/www/docs/customization/milestone.md +++ b/www/docs/customization/milestone.md @@ -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: diff --git a/www/docs/customization/monorepo.md b/www/docs/customization/monorepo.md index 26516a691e5..e0508cc1408 100644 --- a/www/docs/customization/monorepo.md +++ b/www/docs/customization/monorepo.md @@ -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. diff --git a/www/docs/customization/nfpm.md b/www/docs/customization/nfpm.md index 10111f8d94f..a10b28b7c0f 100644 --- a/www/docs/customization/nfpm.md +++ b/www/docs/customization/nfpm.md @@ -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 diff --git a/www/docs/customization/nightlies.md b/www/docs/customization/nightlies.md index 45745cfad6d..cd8ccdb9cd4 100644 --- a/www/docs/customization/nightlies.md +++ b/www/docs/customization/nightlies.md @@ -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/). diff --git a/www/docs/customization/publishers.md b/www/docs/customization/publishers.md index 732a94fa449..99d5ce0d3c9 100644 --- a/www/docs/customization/publishers.md +++ b/www/docs/customization/publishers.md @@ -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/). diff --git a/www/docs/customization/release.md b/www/docs/customization/release.md index 3ac62abe103..f7898830669 100644 --- a/www/docs/customization/release.md +++ b/www/docs/customization/release.md @@ -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. diff --git a/www/docs/customization/sbom.md b/www/docs/customization/sbom.md index bf64ffd85e6..b92780f081e 100644 --- a/www/docs/customization/sbom.md +++ b/www/docs/customization/sbom.md @@ -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. diff --git a/www/docs/customization/scoop.md b/www/docs/customization/scoop.md index 4a484022fd0..1d5518c6f4e 100644 --- a/www/docs/customization/scoop.md +++ b/www/docs/customization/scoop.md @@ -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. diff --git a/www/docs/customization/sign.md b/www/docs/customization/sign.md index c91fc1719ee..35c1d176b29 100644 --- a/www/docs/customization/sign.md +++ b/www/docs/customization/sign.md @@ -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: diff --git a/www/docs/customization/snapcraft.md b/www/docs/customization/snapcraft.md index 9bbe0ae10b0..4abf0b0c4c0 100644 --- a/www/docs/customization/snapcraft.md +++ b/www/docs/customization/snapcraft.md @@ -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 diff --git a/www/docs/customization/snapshots.md b/www/docs/customization/snapshots.md index 737f6b36165..6ca407ea341 100644 --- a/www/docs/customization/snapshots.md +++ b/www/docs/customization/snapshots.md @@ -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/); diff --git a/www/docs/customization/source.md b/www/docs/customization/source.md index 8f84eee38e5..31fa2018f99 100644 --- a/www/docs/customization/source.md +++ b/www/docs/customization/source.md @@ -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 diff --git a/www/docs/customization/templates.md b/www/docs/customization/templates.md index feec830c6b2..ced3cd8de8d 100644 --- a/www/docs/customization/templates.md +++ b/www/docs/customization/templates.md @@ -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. + + ## 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. | - -[^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)'` +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. + +[^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: diff --git a/www/docs/customization/universalbinaries.md b/www/docs/customization/universalbinaries.md index 31e223ad5a6..791ded73574 100644 --- a/www/docs/customization/universalbinaries.md +++ b/www/docs/customization/universalbinaries.md @@ -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 | + + +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 diff --git a/www/docs/customization/upload.md b/www/docs/customization/upload.md index f02e9538f75..706f612ee4c 100644 --- a/www/docs/customization/upload.md +++ b/www/docs/customization/upload.md @@ -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/). diff --git a/www/docs/customization/verifiable_builds.md b/www/docs/customization/verifiable_builds.md index f1cd51b6bf8..ec77bcf015e 100644 --- a/www/docs/customization/verifiable_builds.md +++ b/www/docs/customization/verifiable_builds.md @@ -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 diff --git a/www/docs/errors/dirty.md b/www/docs/errors/dirty.md index 9d901874900..2116e9e68a2 100644 --- a/www/docs/errors/dirty.md +++ b/www/docs/errors/dirty.md @@ -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.