go/goreleaser
1
0
Fork 0
mirror of https://github.com/goreleaser/goreleaser.git synced 2025-10-30 23:58:09 +02:00
Code Issues Releases Activity

docs: rename in the docs goreleaser.yml to goreleaser.yaml (#2784)

Browse Source
This commit is contained in:
Engin Diri
2021-12-23 01:52:01 +01:00
committed by GitHub
parent 30e536ea90
commit a19ee5fc42
58 changed files with 132 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
cmd/root.go
View File

@@ -62,7 +62,7 @@ GoReleaser is built for CI tools, you only need to download and execute it
in your build script. Of course, you can also install it locally if you wish.
You can also customize your entire release process through a
single .goreleaser.yml file.
single .goreleaser.yaml file.
`,
Version: version,
SilenceUsage: true,

2
cmd/testdata/good.yml vendored
View File

@@ -1,4 +1,4 @@
# This is an example .goreleaser.yml file with some sensible defaults.
# This is an example .goreleaser.yaml file with some sensible defaults.
# Make sure to check the documentation at http://goreleaser.com
before:
hooks:

2
www/docs/ci/cloudbuild.md
View File

@@ -6,7 +6,7 @@ your changes are pulled to a repo like
and that's what you're building off.
This repo has the wrong name, so to prevent GoReleaser from publishing to
the wrong GitHub repo, add to your `.goreleaser.yml` file's release section:
the wrong GitHub repo, add to your `.goreleaser.yaml` file's release section:
```yaml
release:

22
www/docs/ci/gitlab.md
View File

@@ -1,18 +1,18 @@
# GitLab CI
Below are some example GitLab CI jobs that use GoReleaser to release a project.
Below are some example GitLab CI jobs that use GoReleaser to release a project.
> If you are using private hosted or Enterprise version of Gitlab, please follow this [guide](/scm/gitlab/) before diving into the details.
## Basic Releasing
You can easily run GoReleaser in GitLab CI using its Docker container.
You can easily run GoReleaser in GitLab CI using its Docker container.
In the repository's GitLab CI settings, add a `GITLAB_TOKEN` variable. The value should
be an API token with `api` scope for a user that has access to the project. This
variable should be masked and optionally protected if the job will only run on
protected branches and tags.
See [Quick Start](https://goreleaser.com/quick-start/) for more information on
See [Quick Start](https://goreleaser.com/quick-start/) for more information on
GoReleaser's environment variables.
Add a `.gitlab-ci.yml` file to the root of the project:
@@ -36,18 +36,18 @@ release:
- goreleaser release --rm-dist
```
Notice that `entrypoint` is intentionally blank. See the
[GitLab documentation on entrypoints](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#overriding-the-entrypoint-of-an-image)
Notice that `entrypoint` is intentionally blank. See the
[GitLab documentation on entrypoints](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#overriding-the-entrypoint-of-an-image)
for more information.
When tags are pushed to the repository,
an available GitLab Runner with the Docker executor will pick up the release job.
`goreleaser/goreleaser` will start in a container and the repository will be mounted inside.
Finally, the `script` section will run within the container starting in your project's directory.
When tags are pushed to the repository,
an available GitLab Runner with the Docker executor will pick up the release job.
`goreleaser/goreleaser` will start in a container and the repository will be mounted inside.
Finally, the `script` section will run within the container starting in your project's directory.
## Releasing Archives and Pushing Images
Pushing images to a registry requires using Docker-in-Docker. To create GitLab releases and push
Pushing images to a registry requires using Docker-in-Docker. To create GitLab releases and push
images to a Docker registry, add a file `.gitlab-ci.yml` to the root of the project:
```yaml
@@ -102,7 +102,7 @@ The secret variables, `DOCKER_PASSWORD` and `GITLAB_TOKEN`, should be masked.
Optionally, you might want to protect them if the job that uses them will only
be run on protected branches or tags.
Make sure the `image_templates` in the file `.goreleaser.yml` reflect that
Make sure the `image_templates` in the file `.goreleaser.yaml` reflect that
custom registry!
Example:

4
www/docs/ci/semaphore.md
View File

@@ -33,14 +33,14 @@ blocks:
# which may be automatic or manual and optionally depend on conditions.
promotions:
- name: Release
pipeline_file: goreleaser.yml
pipeline_file: goreleaser.yaml
auto_promote_on:
- result: passed
branch:
- "^refs/tags/v*"
```
Pipeline file in `.semaphore/goreleaser.yml`:
Pipeline file in `.semaphore/goreleaser.yaml`:
```yaml
version: "v1.0"

2
www/docs/cmd/goreleaser.md
View File

@@ -12,7 +12,7 @@ GoReleaser is built for CI tools, you only need to download and execute it
in your build script. Of course, you can also install it locally if you wish.
You can also customize your entire release process through a
single .goreleaser.yml file.
single .goreleaser.yaml file.
## Options

2
www/docs/cookbooks/build-go-modules.md
View File

@@ -8,7 +8,7 @@ need to setup GoReleaser to "proxy" that module before building it.
To do that, you can simply add this to your config:
```yaml
# goreleaser.yml
# goreleaser.yaml
gomod:
proxy: true
```

2
www/docs/cookbooks/debconf-templates.md
View File

@@ -41,7 +41,7 @@ if [ "$RET" = "false" ]; then
fi
```
Include `templates` and `postinst` in `.goreleaser.yml`:
Include `templates` and `postinst` in `.goreleaser.yaml`:
```yaml
overrides:

4
www/docs/customization/announce/discord.md
View File

@@ -7,10 +7,10 @@ environment variables on your pipeline:
- `DISCORD_WEBHOOK_ID`
- `DISCORD_WEBHOOK_TOKEN`
After this, you can add following section to your `.goreleaser.yml` config:
After this, you can add following section to your `.goreleaser.yaml` config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
discord:
# Whether its enabled or not.

2
www/docs/customization/announce/index.md
View File

@@ -5,7 +5,7 @@ GoReleaser can also announce new releases on social networks, chat rooms and via
It runs at the very end of the pipeline and can be skipped with the `--skip-announce` flag of the [`release`](/cmd/goreleaser_release/) command, or via the skip property:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
# 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`).

4
www/docs/customization/announce/linkedin.md
View File

@@ -7,10 +7,10 @@ For it to work, you'll need to set some environment variables on your pipeline:
!!! warning
We currently don't support posting in groups.
Then, you can add something like the following to your `.goreleaser.yml` config:
Then, you can add something like the following to your `.goreleaser.yaml` config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
linkedin:
# Whether its enabled or not.

4
www/docs/customization/announce/mattermost.md
View File

@@ -5,10 +5,10 @@ environment variables on your pipeline:
- `MATTERMOST_WEBHOOK`
Then, you can add something like the following to your `.goreleaser.yml` config:
Then, you can add something like the following to your `.goreleaser.yaml` config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
mattermost:
# Whether its enabled or not.

4
www/docs/customization/announce/reddit.md
View File

@@ -6,10 +6,10 @@ variables on your pipeline:
- `REDDIT_SECRET`
- `REDDIT_PASSWORD`
Then, you can add something like the following to your `.goreleaser.yml` config:
Then, you can add something like the following to your `.goreleaser.yaml` config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
reddit:
# Whether its enabled or not.

4
www/docs/customization/announce/slack.md
View File

@@ -5,10 +5,10 @@ environment variables on your pipeline:
- `SLACK_WEBHOOK`
Then, you can add something like the following to your `.goreleaser.yml` config:
Then, you can add something like the following to your `.goreleaser.yaml` config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
slack:
# Whether its enabled or not.

4
www/docs/customization/announce/smtp.md
View File

@@ -4,10 +4,10 @@ For it to work, you'll need to set some environment variables on your pipeline:
- `SMTP_PASSWORD`
Then, you can add something like the following to your `.goreleaser.yml` config:
Then, you can add something like the following to your `.goreleaser.yaml` config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
smtp:
# Whether its enabled or not.

4
www/docs/customization/announce/teams.md
View File

@@ -6,10 +6,10 @@ to [create a Webhook](https://docs.microsoft.com/en-us/microsoftteams/platform/w
- `TEAMS_WEBHOOK`
After this, you can add following section to your `.goreleaser.yml` config:
After this, you can add following section to your `.goreleaser.yaml` config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
teams:
# Whether its enabled or not.

4
www/docs/customization/announce/telegram.md
View File

@@ -7,10 +7,10 @@ some environment variables on your pipeline:
Also you need to know your channel's chat ID to talk with.
Then, you can add something like the following to your `.goreleaser.yml` config:
Then, you can add something like the following to your `.goreleaser.yaml` config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
telegram:
# Whether its enabled or not.

4
www/docs/customization/announce/twitter.md
View File

@@ -8,10 +8,10 @@ some environment variables on your pipeline:
- `TWITTER_ACCESS_TOKEN`
- `TWITTER_ACCESS_TOKEN_SECRET`
Then, you can add something like the following to your `.goreleaser.yml` config:
Then, you can add something like the following to your `.goreleaser.yaml` config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
announce:
twitter:
# Whether its enabled or not.

8
www/docs/customization/archive.md
View File

@@ -7,7 +7,7 @@ additional files, and format.
Here is a commented `archives` section with all fields specified:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
archives:
-
# ID of this archive.
@@ -148,7 +148,7 @@ on the archive section.
A working hack is to use something like this:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
archives:
- files:
- none*
@@ -169,7 +169,7 @@ Presumably, you'll want that file to be the binary, so, your archive section
will probably look like this:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
archives:
- format: gz
files:
@@ -188,7 +188,7 @@ extracted with something like `gzip -d file.gz`.
You can do that by setting `format` to `binary`:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
archives:
- format: binary
```

4
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.yml` file:
upload target and a username to your `.goreleaser.yaml` file:
```yaml
artifactories:
@@ -115,7 +115,7 @@ puts:
Of course, you can customize a lot of things:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
artifactories:
# You can have multiple Artifactory instances.
-

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

@@ -6,7 +6,7 @@ Google GCS.
## Customization
```yaml
# .goreleaser.yml
# .goreleaser.yaml
blobs:
# You can have multiple blob configs
-

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

@@ -8,7 +8,7 @@ the name of the binary, flags, environment variables, hooks and etc.
Here is a commented `builds` section with all fields specified:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
# You can have multiple builds defined as a yaml list
-
@@ -163,7 +163,7 @@ builds:
Here is an example with multiple binaries:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
- main: ./cmd/cli
id: "cli"
@@ -206,7 +206,7 @@ You can do that by using `{{ .Env.VARIABLE_NAME }}` in the template, for
example:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
- ldflags:
- -s -w -X "main.goversion={{.Env.GOVERSION}}"
@@ -228,7 +228,7 @@ In addition to simple declarations as shown above _multiple_ hooks can be declar
to help retaining reusability of config between different build environments.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
-
id: "with-hooks"
@@ -247,7 +247,7 @@ builds:
Each hook can also have its own work directory and environment variables:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
-
id: "with-hooks"
@@ -287,10 +287,10 @@ Environment variables are inherited and overridden in the following order:
very likely to fail.
You can solve this by running `go mod tidy` before calling `goreleaser` or
by adding a [hook][] doing that on your `.goreleaser.yml` file:
by adding a [hook][] doing that on your `.goreleaser.yaml` file:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
before:
hooks:
- go mod tidy
@@ -330,7 +330,7 @@ Reasons you might want to do that include:
In any case, its pretty easy to do that now:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
-
# Set the builder to prebuilt
@@ -366,9 +366,9 @@ There is no difference in how the binaries are handled.
!!! tip
A cool tip here, specially when using CGO, is that you can have one
`.goreleaser.yml` file just for the builds, build each in its own machine
`.goreleaser.yaml` file just for the builds, build each in its own machine
with [`goreleaser build --single-target`](/cmd/goreleaser_build/) and
have a second `.goreleaser.yml` file that imports those binaries
have a second `.goreleaser.yaml` file that imports those binaries
and release them.
This tip can also be used to speed up the build process if you run all the
builds in different machines in parallel.

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

@@ -6,7 +6,7 @@ release, so your users can validate if the downloaded files are correct.
The `checksum` section allows customizations of the filename:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
checksum:
# You can change the name of the checksums file.
# Default is `{{ .ProjectName }}_{{ .Version }}_checksums.txt`.

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

@@ -1,9 +1,9 @@
# Dist folder
By default, GoReleaser will create its artifacts in the `./dist` folder.
If you must, you can change it by setting it in the `.goreleaser.yml` file:
If you must, you can change it by setting it in the `.goreleaser.yaml` file:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
dist: another-folder-that-is-not-dist
```

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

@@ -11,7 +11,7 @@ by your `nfpms` section.
If you have only one `build` setup,
the configuration is as easy as adding the
name of your image to your `.goreleaser.yml` file:
name of your image to your `.goreleaser.yaml` file:
```yaml
dockers:
@@ -42,7 +42,7 @@ This configuration will build and push a Docker image named `user/repo:tagname`.
Of course, you can customize a lot of things:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
dockers:
# You can have multiple Docker images.
-
@@ -134,7 +134,7 @@ Some users might want to keep their image name as generic as possible.
That can be accomplished simply by adding template language in the definition:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
project: foo
dockers:
-
@@ -156,7 +156,7 @@ Some users might want to push docker tags `:v1`, `:v1.6`,
accomplished by using multiple `image_templates`:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
dockers:
-
image_templates:
@@ -185,7 +185,7 @@ Some users might want to push images to multiple docker registries. That can be
accomplished by using multiple `image_templates`:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
dockers:
-
image_templates:
@@ -208,7 +208,7 @@ Build flags can be applied using `build_flag_templates`.
The flags must be valid Docker build flags.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
dockers:
-
image_templates:
@@ -243,7 +243,7 @@ docker build -t myuser/myimage . \
You can use [`podman`](https://podman.io) instead of `docker` by setting `use` to `podman` on your config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
dockers:
-
image_templates:
@@ -258,7 +258,7 @@ Note that GoReleaser will not install Podman for you, nor change any of its conf
You can use [`buildpacks`](https://buildpacks.io) instead of `docker` by setting `use` to `buildpacks` on your config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
dockers:
-
image_templates:
@@ -270,7 +270,7 @@ Also, you can use a custom buildpack on `build_flag_templates` if you want.
By default, `gcr.io/buildpacks/builder:v1` will be used.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
dockers:
-
image_templates:

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

@@ -25,7 +25,7 @@ You can create several manifests in a single GoReleaser run, here are all the
options available:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
docker_manifests:
# You can have multiple Docker manifests.
-
@@ -104,7 +104,7 @@ Then, on our GoReleaser config file, we need to define both the `dockers` and
the `docker_manifests` section:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
- env:
- CGO_ENABLED=0
@@ -149,7 +149,7 @@ and push everything to Docker Hub.
You can use [`podman`](https://podman.io) instead of `docker` by setting `use` to `podman` on your config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
docker_manifests:
- name_template: foo/bar:{{ .Version }}
image_templates:

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

@@ -2,10 +2,10 @@
Global environment variables to be passed down to all hooks and builds.
This is useful for `GO111MODULE`, for example. You can have your `.goreleaser.yml` file like the following:
This is useful for `GO111MODULE`, for example. You can have your `.goreleaser.yaml` file like the following:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
env:
- GO111MODULE=on
- FOO={{ .Env.FOOBAR }}

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

@@ -13,7 +13,7 @@ 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`:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
furies:
- account: myaccount
```
@@ -25,7 +25,7 @@ This will automatically upload all your `deb` and `rpm` files.
You can also have plenty of customization options:
```yaml
# goreleaser.yml
# goreleaser.yaml
furies:
-

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

@@ -11,7 +11,7 @@ and the
for more details.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
rigs:
-
# Name template of the recipe

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

@@ -8,7 +8,7 @@ A GoReleaser-created verifiable build will include module information in the res
Configuration options available are described below.
```yaml
# goreleaser.yml
# goreleaser.yaml
gomod:
# Proxy a module from proxy.golang.org, making the builds verifiable.

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

@@ -11,7 +11,7 @@ and the
for more details.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
brews:
-
# Name template of the recipe

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

@@ -10,7 +10,7 @@ GoReleaser allows this with the global hooks feature.
The configuration is straightforward, here is an example will all possible options:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
before:
# Templates for the commands to be ran.
hooks:
@@ -30,7 +30,7 @@ GoReleaser allows this with the global hooks feature.
The configuration is straightforward, here is an example will all possible options:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
# global before hooks
before:
# Templates for the commands to be ran.

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

@@ -8,16 +8,16 @@ GoReleaser allows you to include other files from an URL or in the current files
Files are included recursively in the order they are declared.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
includes:
- from_file:
path: ./config/goreleaser.yml
path: ./config/goreleaser.yaml
- from_url:
url: https://raw.githubusercontent.com/goreleaser/goreleaser/main/.goreleaser.yml
url: https://raw.githubusercontent.com/goreleaser/goreleaser/main/.goreleaser.yaml
- from_url:
url: caarlos0/goreleaserfiles/main/packages.yml # the https://raw.githubusercontent.com/ prefix may be ommited
- from_url:
url: https://api.mycompany.com/configs/goreleaser.yml
url: https://api.mycompany.com/configs/goreleaser.yaml
headers:
# header values are expanded in case they are environment variables
x-api-token: "${MYCOMPANY_TOKEN}"

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

@@ -1,6 +1,6 @@
# Customization
GoReleaser can be customized by tweaking a `.goreleaser.yml` file.
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.

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

@@ -7,7 +7,7 @@ Check their [website](https://krew.sigs.k8s.io) for more information.
The `krews` section specifies how the plugins should be created:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
krews:
-
# Name template of the recipe

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

@@ -5,7 +5,7 @@ GoReleaser can close repository milestones after successfully publishing all art
Let's see what can be customized in the `milestones` section:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
milestones:
# You can have multiple milestone configs
-

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

@@ -11,10 +11,10 @@ You create your tags like `subproject1/v1.2.3` and `subproject2/v1.2.3`.
## Usage
You'll need to create a `.goreleaser.yml` 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.yml
# subroj1/.goreleaser.yaml
project_name: subproj1
monorepo:
@@ -25,7 +25,7 @@ monorepo:
Then, you can release with (from the project's root directory):
```sh
goreleaser release --rm-dist -f ./subproj1/.goreleaser.yml
goreleaser release --rm-dist -f ./subproj1/.goreleaser.yaml
```
Then, the following is different from a "regular" run:

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

@@ -6,7 +6,7 @@ generate and publish `.deb`, `.rpm` and `.apk` packages.
Available options:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
nfpms:
# note that this is an array of nfpm configs
-

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

@@ -5,6 +5,6 @@ If none is given, it will be inferred from the name of the GitHub, GitLab, or
Gitea release.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
project_name: myproject
```

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

@@ -14,7 +14,7 @@ In other words the publisher is expected to be safe to run
in multiple instances in parallel.
If you have only one `publishers` instance, the configuration is as easy as adding
the command to your `.goreleaser.yml` file:
the command to your `.goreleaser.yaml` file:
```yaml
publishers:
@@ -88,7 +88,7 @@ Supported variables:
Of course, you can customize a lot of things:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
publishers:
-
# Unique name of your publisher. Used for identification

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

@@ -9,7 +9,7 @@ previous tag.
Let's see what can be customized in the `release` section for GitHub:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
release:
# Repo in which the release will be created.
# Default is extracted from the origin remote URL or empty if its private hosted.
@@ -96,7 +96,7 @@ release:
Let's see what can be customized in the `release` section for GitLab.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
release:
# 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
@@ -158,7 +158,7 @@ release:
You can also configure the `release` section to upload to a [Gitea](https://gitea.io) instance:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
release:
# Default is empty.
gitea:

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

@@ -7,7 +7,7 @@ The `scoop` section specifies how the manifest should be created. See
the commented example below:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
scoop:
# 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 }}"

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

@@ -16,7 +16,7 @@ with [GnuPG](https://www.gnupg.org/) and your default key. To enable signing
just add
```yaml
# .goreleaser.yml
# .goreleaser.yaml
signs:
- artifacts: checksum
```
@@ -24,7 +24,7 @@ signs:
To customize the signing pipeline you can use the following options:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
signs:
-
# ID of the sign config, must be unique.
@@ -122,7 +122,7 @@ You can sign you 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:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
signs:
- cmd: cosign
stdin: '{{ .Env.COSIGN_PWD }}'
@@ -147,7 +147,7 @@ Executables can be signed after build using post hooks.
For example, you can use [gon][] to create notarized MacOS apps:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
- binary: foo
id: foo
@@ -205,7 +205,7 @@ 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.yml
# .goreleaser.yaml
builds:
- hooks:
post:
@@ -236,7 +236,7 @@ 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:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
signs:
- cmd: sh
args:

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

@@ -12,7 +12,7 @@ You can read more about it in the [snapcraft docs](https://snapcraft.io/docs/).
Available options:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
snapcrafts:
-
# ID of the snapcraft config, must be unique.

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

@@ -7,7 +7,7 @@ GoReleaser supports this with the `--snapshot` flag
and also with the `snapshot` customization section:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
snapshot:
# Allows you to change the name of the generated snapshot
#

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

@@ -4,7 +4,7 @@ You may add the current tag source archive to the release as well. This is parti
useful if you want to sign it, for example.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
source:
# Whether this pipe is enabled or not.
# Defaults to `false`

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

@@ -134,7 +134,7 @@ This feature is specially useful with [includes](/customization/includes/), so y
Usage is as simple as you would expect:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
variables:
description: my project description
somethingElse: yada yada yada

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

@@ -6,7 +6,7 @@ Those binaries are in a special format that contains both `arm64` and `amd64` ex
Here's how to use it:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
universal_binaries:
-
# ID of the source build

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

@@ -9,7 +9,7 @@ You can declare multiple `uploads` instances. All binaries generated by your
`builds` section will be pushed to each configured upload.
If you have only one `uploads` instance, the configuration is as easy as adding
the upload target and a name to your `.goreleaser.yml` file:
the upload target and a name to your `.goreleaser.yaml` file:
```yaml
uploads:
@@ -122,7 +122,7 @@ uploads:
Of course, you can customize a lot of things:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
uploads:
# You can have multiple upload instances.
-

2
www/docs/deprecations.md
View File

@@ -680,7 +680,7 @@ FPM is deprecated in favor of nfpm, which is a simpler alternative written
in Go. The objective is to remove the ruby dependency thus simplify the
CI/CD pipelines.
Just replace the `fpm` keyword by `nfpm` in your `.goreleaser.yml` file.
Just replace the `fpm` keyword by `nfpm` in your `.goreleaser.yaml` file.
=== "Before"
```yaml

6
www/docs/errors/no-main.md
View File

@@ -1,6 +1,6 @@
# Build does not contain a main function
This usually happens if you're trying to build a library or if you didn't setup the `builds.main` section in your `.goreleaser.yml` and you `main.go` is not in the root folder.
This usually happens if you're trying to build a library or if you didn't setup the `builds.main` section in your `.goreleaser.yaml` and you `main.go` is not in the root folder.
Here's an example error:
@@ -15,7 +15,7 @@ Learn more at https://goreleaser.com/errors/no-main
Add something like this to your config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
- skip: true
```
@@ -25,7 +25,7 @@ builds:
Add something like this to your config:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
builds:
- main: ./path/to/your/main/pkg/
```

4
www/docs/errors/resource-not-accessible-by-integration.md
View File

@@ -24,7 +24,7 @@ You can create a PAT and use it for the entire GoReleaser action run.
You'll need to add it as secret and pass it to the action, for instance:
```yaml
# .github/workflows/goreleaser.yml
# .github/workflows/goreleaser.yaml
# ...
- uses: goreleaser/goreleaser-action@v2
env:
@@ -41,7 +41,7 @@ Let's see, for example, how it would look like for Homebrew Taps.
We would need to change the workflow file:
```yaml
# .github/workflows/goreleaser.yml
# .github/workflows/goreleaser.yaml
# ...
- uses: goreleaser/goreleaser-action@v2
env:

2
www/docs/how-it-works.md
View File

@@ -5,7 +5,7 @@ Ideally, using sensible defaults and making the most common usecases easy.
GoReleaser expects a couple of things:
- a `.goreleaser.yml` file with the configuration (see the [customization section](/customization) for more info)
- a `.goreleaser.yaml` file with the configuration (see the [customization section](/customization) for more info)
- a clean working tree
- a SemVer-compatible version (e.g. `10.21.34-something`)

2
www/docs/intro.md
View File

@@ -6,7 +6,7 @@ The goal is to simplify the build, release and publish steps while providing var
GoReleaser is built with CI tools in mind, you only need to download and execute it in your build script.
Of course, you can still install it locally if you want.
Your release process can be customized through a `.goreleaser.yml` file.
Your release process can be customized through a `.goreleaser.yaml` file.
Once you set it up, every time you want to create a new release, all you need to do is tag and run `goreleaser release`:

8
www/docs/quick-start.md
View File

@@ -13,7 +13,7 @@ func main() {
}
```
Run the [init](/cmd/goreleaser_init/) command to create an example `.goreleaser.yml` file:
Run the [init](/cmd/goreleaser_init/) command to create an example `.goreleaser.yaml` file:
```sh
goreleaser init
@@ -25,10 +25,10 @@ Now, lets run a "local-only" release to see if it works using the [release](/cmd
goreleaser release --snapshot --rm-dist
```
At this point, you can [customize](/customization/) the generated `.goreleaser.yml` or leave it as-is, it's up to you.
It is best practice to check `.goreleaser.yml` into the source control.
At this point, you can [customize](/customization/) the generated `.goreleaser.yaml` or leave it as-is, it's up to you.
It is best practice to check `.goreleaser.yaml` into the source control.
You can verify your `.goreleaser.yml` is valid by running the [check](/cmd/goreleaser_check/) command:
You can verify your `.goreleaser.yaml` is valid by running the [check](/cmd/goreleaser_check/) command:
```sh
goreleaser check

8
www/docs/scm/gitea.md
View File

@@ -8,10 +8,10 @@ You can create one in `Settings | Applications | Generate New Token` page of you
This token should be added to the environment variables as `GITEA_TOKEN`.
Alternatively, you can provide the Gitea token in a file.
GoReleaser will check `~/.config/goreleaser/gitea_token` by default, but you can change that in the `.goreleaser.yml` file:
GoReleaser will check `~/.config/goreleaser/gitea_token` by default, but you can change that in the `.goreleaser.yaml` file:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
env_files:
gitea_token: ~/.path/to/my/gitea_token
```
@@ -19,10 +19,10 @@ env_files:
## URLs
You can use GoReleaser with Gitea by providing its URLs in
the `.goreleaser.yml` configuration file. This takes a normal string or a template value.
the `.goreleaser.yaml` configuration file. This takes a normal string or a template value.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
gitea_urls:
api: https://gitea.myinstance.com/api/v1/
download: https://gitea.myinstance.com

8
www/docs/scm/github.md
View File

@@ -8,10 +8,10 @@ You can create one [here](https://github.com/settings/tokens/new).
This token should be added to the environment variables as `GITHUB_TOKEN`.
Alternatively, you can provide the GitHub token in a file.
GoReleaser will check `~/.config/goreleaser/github_token` by default, but you can change that in the `.goreleaser.yml` file:
GoReleaser will check `~/.config/goreleaser/github_token` by default, but you can change that in the `.goreleaser.yaml` file:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
env_files:
github_token: ~/.path/to/my/github_token
```
@@ -19,11 +19,11 @@ env_files:
## GitHub Enterprise
You can use GoReleaser with GitHub Enterprise by providing its URLs in the
`.goreleaser.yml` configuration file. This takes a normal string or a template
`.goreleaser.yaml` configuration file. This takes a normal string or a template
value.
```yaml
# .goreleaser.yml
# .goreleaser.yaml
github_urls:
api: https://git.company.com/api/v3/
upload: https://git.company.com/api/uploads/

4
www/docs/scm/gitlab.md
View File

@@ -8,10 +8,10 @@ You can create one [here](https://gitlab.com/-/profile/personal_access_tokens).
This token should be added to the environment variables as `GITLAB_TOKEN`.
Alternatively, you can provide the GitLab token in a file.
GoReleaser will check `~/.config/goreleaser/gitlab_token` by default, but you can change that in the `.goreleaser.yml` file:
GoReleaser will check `~/.config/goreleaser/gitlab_token` by default, but you can change that in the `.goreleaser.yaml` file:
```yaml
# .goreleaser.yml
# .goreleaser.yaml
env_files:
gitlab_token: ~/.path/to/my/gitlab_token
```