GoReleaser requires an API token with the
api scope selected to deploy the artifacts to GitLab. That token can either be a Personal, or a Project one.
This token should be added to the environment variables as
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.yaml env_files: gitlab_token: ~/.path/to/my/gitlab_token
If you use a project access token, make sure to set
true as well, otherwise it might not work.
If you are using a protected variable to store any of the values needed by goreleaser, ensure that you are protecting the tags as CI jobs in Gitlab only may access protected variables if the job is run for protected refs (branches, tags).
GitLab Enterprise or private hosted¶
You can use GoReleaser with GitLab Enterprise by providing its URLs in the
.goreleaser.yml configuration file. This takes a normal string, or a template value.
# .goreleaser.yml gitlab_urls: api: https://gitlab.mycompany.com/api/v4/ download: https://gitlab.company.com # set to true if you use a self-signed certificate skip_tls_verify: false # set to true if you want to upload to the Package Registry rather than attachments # Only works with GitLab 13.5+ # # Since: v1.3 use_package_registry: false # Set this if you set GITLAB_TOKEN to the value of CI_JOB_TOKEN. # # Since: v1.11 use_job_token: true
If none are set, they default to GitLab's public URLs.
Generic Package Registry¶
GitLab introduced the Generic Package Registry in Gitlab 13.5.
goreleaser uploads release files as "attachments", which may have administrative limits. Notably, hosted GitLab instances have a 10MB attachment limit, which cannot be changed.
Uploading to the Generic Package Registry does not have this restriction. To use it instead, set
# .goreleaser.yml gitlab_urls: use_package_registry: true
Here's an example of what the release might look like: