- [x] if the default is the zero-value for the field, do not specify
- [ ] TODO: add a "how to read this docs" section somewhere explaining
that
- [x] if the change was introduced in a v1.x.0, say only v1.x
- [x] drop trail ending `.` from Since, Default, etc
- [x] wording: always use `Default: ` instead of `Defaults to` and
others
- [x] add a note to templateable fields
- [x] default value of a field, if its a string, always between single
quotes `'`
---------
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
add warning about gitlab-ci protected variables for both CI/gitlab and
SCM/gitlab.
Failing to run the pipelines on a protected ref will cause goreleaser to
fail with `401: unauthorized` if for example, GITLAB_TOKEN is a
protected variable and the CI Job is running on a tag that is not
protected.
<!--
Hi, thanks for contributing!
Please make sure you read our CONTRIBUTING guide.
Also, add tests and the respective documentation changes as well.
-->
<!-- If applied, this commit will... -->
Add a warning about Gitlab CI and protected variables
<!-- Why is this change being made? -->
To prevent future users from running into issues with protected
variables.
<!-- # Provide links to any relevant tickets, URLs or other resources
-->
[Discord
Convo](https://discord.com/channels/890434333251362866/890434334803247126/1038130560293412955)
This PR adds explicit mention of Gitea in the AUR, Homebrew and Scoop
sections.
I have tested and tried using Homebrew and Scoop with a Gitea instance,
I have not tried the AUR but it should work the same.
versioned all new options since v1.2 (late 2021).
Should be enough to fix#3317 for now.
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* Make sure to do required go mod init before continuing or goreleaser command fails.
* how the release might look like -> what the release might look like
* How does it look like -> What does it look like
* you must therefore -> you must
* Don't use GO111MODULES in example since it's so obsolete
* modules -> verifiable builds
* got you covered -> has you covered
GitLab's Generic Package Repository allows uploading files
to GitLab, as an alternative to attachments.
Added the flag `use_package_registry` to the `gitlab_urls` config.
When false, the default, it will behave as before.
When true, it will publish the file to the Generic Package Registry.
Either way, the URL is bound to the release the same
Updated `go-gitlab` to version 0.52.2 which has the new
`GenericPackages.PublishPackageFile` function.
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
Background
---
When a git repository is hosted in multiple GitLab instances the
`.goreleaser.yml` needs to take in consideration both APIs endpoints. At
the moment it defaults to GitLab.com and you can override it with
`gitlab_urls` however this forces you to only support 1 GitLab instance.
We need this for
https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/14122
where we have a tool that is developed on GitLab.com but then mirrored
to an internal GitLab instance since we need it to operate GitLab.com
even when it's down.
Solution
---
Support templates like `{{ .Env.CI_SERVER_URL }}` for the
`gitlab_urls`, `github_urls` and `gitea_urls` so it can use environment
variables and the same `.goreleaser` file can be used in multiple SCM
instances.
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
