GoReleaser – Blog

Announcing GoReleaser v2.15

Sun, 29 Mar 2026 00:00:00 +0000

This version a big one for Linux packaging - Flatpak bundles and Source RPMs land in the same release, alongside a rebuilt documentation website and better Go build defaults.

Flatpak

GoReleaser can now build and publish Flatpak bundles!

Flatpak lets you distribute Linux desktop applications as self-contained bundles that run on any distro, inside a sandboxed environment with a predictable runtime. A minimal example:

.goreleaser.yaml

flatpak:
 - app_id: com.example.MyApp
 runtime: org.freedesktop.Platform
 runtime_version: "24.08"
 sdk: org.freedesktop.Sdk

The app_id, runtime, runtime_version, and sdk fields are required. You can also set finish_args to configure sandbox permissions:

.goreleaser.yaml

flatpak:
 - app_id: com.example.MyApp
 runtime: org.freedesktop.Platform
 runtime_version: "24.08"
 sdk: org.freedesktop.Sdk
 finish_args:
 - --share=network
 - --socket=wayland
 - --filesystem=home

Flatpak bundles are automatically included in checksums and signing.

See the documentation for more details.

Go build `./...` and better defaults

The Go builder now supports ./... as a build target. GoReleaser will find all packages with a main function, infer their binary names just like go build does, and build them all at once:

.goreleaser.yaml

builds:
 - main: ./...

Less config, and faster builds — Go can schedule all packages together in a single compiler invocation, which matters for repos with multiple binaries.

goreleaser init also generates better defaults now, including goarch and main, so there’s even less to fill in by hand.

Generate completions in Homebrew Casks

Homebrew Casks now support the generate_completions_from_executable stanza. Users installing your tool via Homebrew will get shell completions automatically, without any extra manual steps:

.goreleaser.yaml

homebrew_casks:
 - generate_completions_from_executable: true

See the documentation for more details.

Note

This feature was just recently introduced in Homebrew.

Source RPMs

GoReleaser can now generate Source RPM (.src.rpm) packages!

This one has been a long time coming - the feature request dates back to 2022, and it’s finally here. Huge thanks to Tom Payne for working on it!

Source RPMs are how RPM-based distributions (Fedora, RHEL, CentOS, etc.) package software for redistribution and rebuilding. They bundle the source archive together with a .spec file that describes how to produce binary RPMs.

A minimal example:

.goreleaser.yaml

srpm:
 enabled: true
 spec_file: myproject.spec.tmpl
 summary: My project summary
 license: MIT
 url: https://myproject.example.com

See the documentation for the full list of configuration fields and an example Fedora-style spec template.

New website

We migrated the documentation website from Material for MkDocs to Hugo with the Hextra theme.

The new site is faster, and we took the opportunity to clean up and improve the docs along the way.

If you run into any broken links, please let us know — or open a PR adding a redirect to the _redirects file.

You can read the full announcement here.

Before publish installer types and SBOM support

Note

These features are only available in the Pro plans.

The before_publish hook now works with NSIS and .pkg installer types, so you can run scripts before those artifacts are published.

The SBOM pipe now covers installer types too — you can generate SBOMs for your .pkg and NSIS installers alongside your binaries.

We also fixed a handful of rough edges left over from v2.14: NSIS and .pkg artifacts are now correctly uploaded to releases and blob storage, play nicely with the custom publisher, and are included when signing installers.

Other updates

checksums: added BLAKE3 checksumming support
telegram: added message_thread_id to post to a specific supergroup thread; fixed response body not being closed
gomod: retry Go mod proxy fetches on 404 with exponential backoff
homebrew_casks: fixed stanza order; use heredoc for caveats to handle shell metacharacters
docker: check if --provenance and --sbom flags are available before using them
rust: support cargo-zigbuild targets with custom glibc versions
go: removed windows/arm from valid build targets
release: fixed ignore_tags filtering when multiple tags are set
pro/changelog: fixed changelog generation on the first release

Other news

GoReleaser now has ~15.7k stars and 458 contributors! Thanks, everyone!
We often discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries from GitHub:

Install v2.15.0 (OSS) v2.15.0 (Pro)

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Get the Pro license Sponsor the project

Goodbye, Mkdocs

Sun, 22 Mar 2026 00:00:00 +0000

We migrated from Material for Mkdocs to Hugo.

This is a FYI.

The site now is built with Hugo using the Hextra themel

Please, let me know of any feedback you might have.

Note

I did my best to keep the old URLs working - if you happen to find a 404, its because it slipped through the cracks. Please, let me know, or open a PR adding it to the redirects file.

Thank you, see again you soon!

Announcing GoReleaser v2.14

Sat, 21 Feb 2026 00:00:00 +0000

Happy 2026! The first release of the year is here, and it is packed with goodies!

GitHub Secure Open Source Func

GoReleaser was one of the projects participating in the session 3 of the GitHub Secure Open Source Fund.

You can read the announcement here.

Finally, air-gapped license checks

If you need to release in an air-gapped environment, you may now export your key and validate it offline:

goreleaser license-export -k your-key -o goreleaser.key
goreleaser license-verify -k goreleaser.key

The license will be valid for at most 3 months, or your next billing cycle, whichever happens first.

As you may have noticed, the $GORELEASER_KEY and the --key flag can now also point to a file instead of plain text.

Note

This feature is only available in the Business and Enterprise plans.

Better changelogs

On nightly builds, you may now use github, gitlab, and gitea changelog implementations (instead of rolling back to git), which should help you have more similar-to-production changelogs.

You can now also include co-authors in the changelogs:

.goreleaser.yaml

changelog:
 format: "{{ .SHA }}: {{ .Message }}{{ if .Logins }} ({{ .Logins | englishJoin }}){{ end }}"

macOS `.pkg` installers

GoReleaser Pro can now create, sign, and notarize .pkg installers for macOS!

A minimal example:

.goreleaser.yaml

pkgs:
 - identifier: org.example.foo

See the documentation for more details.

Windows installers

You can also create Windows installers with the Nullsoft Scriptable Install System (NSIS).

Example:

.goreleaser.yaml

nsis:
 - script: ./path/to/script.nsis

You will, of course, need to create your own .nsis script file. Maybe we add a sensible default in the future, but for now, this is a requirement. You can of course use the example provided in the documentation and it should just work.

On the same not, MSI installers can now use hooks as well.

Docker v2 improvements

The next version of the Docker feature has a couple improvements, like allowing to template the platforms field, better support for daemonless snapshot builds, and warning the user if it looks like they’re rebuilding the binaries inside the Dockerfile.

Homebrew Casks

Continuing our efforts in replacing the old, hackey brews with Homebrew Casks, we now allow users to glob manpages, as well as fixed the Cask generation for archives that use wrap_in_directory.

See the documentation and migration guide.

Dynamically linked binaries

GoReleaser will now detect if the binary is dynamically, and better generate Nix derivations based on that (namely, use autoPatchelfHook, stdenv.cc, etc).

Better, safer, output

We made some improvements on our internal gerrors package, which should allow us to give better, more detailed, error outputs.

And speaking of outputs, all relevant exec.Command calls now have their output go through a redactor, which will replace secret-looking environment variables with their keys in output.

We also made improvements to our logging library, so when you use --verbose, command outputs look a bit better.

Deprecations

The furies key always sounded weird to me, so it will be renamed to gemfury. Going forward, we will make all the keys that refer to a specific technology singular to prevent these weird readings.

GitHub Action

We also updated our GitHub Action. It now works on Node 24 and was converted to ESM.

See the complete release notes.

Other updates

nfpm: allow to filter by GOAMD64
nfpm: added support to ARCHVARIANT for .deb
nfpm: properly handle meta packages
nix: add a formatter option
winget: allow to set the package name
tmpl: englishJoin function
aur: fix invalid use of ${pkgver} in the SRCINFO file
github: fix GitHub enterprise URLs
dockers/v2: better log outputs and driver warning
docker: fixed regression with new buildx versions
sbom: better log output

Other news

GoReleaser now has ~15.6k stars and 455 contributors! Thanks, everyone!
We often discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.
The GoReleaser Action had new releases, check it out

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries from GitHub:

Install v2.14.0 (OSS) v2.14.0 (Pro)

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Get the Pro license Sponsor the project

How GoReleaser strengthened security through GitHub's Secure Open Source Fund

Tue, 17 Feb 2026 00:00:00 +0000

GoReleaser builds and ships release artifacts for thousands of projects, making it a high-value supply-chain target. That’s why we were thrilled to be selected for the third session of the GitHub Secure Open Source Fund.

We joined a group with so many great projects that I feel bad trying to name just a few of them - so you should check the official announcement for the full list!

That said, in that session we did a lot of improvements in GoReleaser. Just to name a few:

Better documentation and understanding of attack surface (e.g. IRP, Threat Modeling, etc)
Wrote a lot of security-related documentation
Using SARIF for all security scanners - and added more of them
Improved GitHub Actions usage to be more secure
Reviewed dependencies
Reviewed and improved SBOMs
Using OIDC to publish NPM packages
And many more!

Granted, we were already doing some things right, mostly thanks to the feedback of our amazing community. For instance, we had signing, SBOMs, and private vulnerability reports for a long time.

Still, there’s always room for improvement!

Go is a solid platform, actually

One interesting thing I realized whilst talking with other maintainers is that Go has amazing tools for security.

For instance:

Go has fuzzing built-in, which is something we definitely want to take more advantage of in the coming months.
govulncheck is amazing as well, and every Go-based project should run it as part of their pipeline.
SBOMs can be easily generated with off-the-shelf tools like syft.

While some projects had to use external dependencies or write custom software to do some of these things, with Go, it was really easy!

By the way, if you want to make your GoReleaser-powered project a bit more secure, check out this secure example repository: it is using many of the good practices learned during the session.

Looking forward

Security work is never really done. There’s a long road ahead, but I feel like we are way more secure now than before.

If you are interested in security, or just want to help, I’m always available on the GoReleaser Discord - feel free to chime in there and let’s chat. 🙏 GitHub discussions are also open.

Our greatest thanks to both the fund and the fund’s partners for making this possible.

Announcing GoReleaser v2.13

Sun, 30 Nov 2025 00:00:00 +0000

Happy thanksgiving - GoReleaser v2.13 is here!

GitHub Universe and GoLab Firenze

If you attended these events, you might have gotten yourself some GoReleaser stickers!

We also had a booth on GitHub Universe day 1!

I don’t usually do this kind of thing, but it was pretty fun! Thanks to everyone that passed by to chat, and thanks specially to Abby and Lee from GitHub for inviting me!

All about MCP

Big news here!

First, GoReleaser now supports publishing MCPs to the Model Context Protocol Registry!

See this example:

.goreleaser.yaml

mcp:
 name: "io.github.goreleaser/mcp"
 title: "The MCP server for GoReleaser"
 repository:
 source: "github"
 url: "https://github.com/goreleaser/mcp"
 auth:
 type: "github-oidc"
 packages:
 - registry_type: oci
 identifier: "ghcr.io/goreleaser/mcp:{{ .Version }}"
 transport:
 type: stdio
 - registry_type: npm
 identifier: "@goreleaser/mcp"
 transport:
 type: stdio

So, GoReleaser MCP is published in the MCP Registry!

And the second news is that the GoReleaser MCP now has its own repository. This should allow us to evolve it faster, and also, if you only want the MCP, the binary is much smaller.

One good use case for our MCP is that it provides a ready to use prompt + tools to update your configuration, fixing deprecated options.

Here’s how it looks like on Charm’s Crush:

There’s also a prompt to fix all the issues with Cosign v3.

Make sure to give it a try!

Relevant links:

GoReleaser Pro

For Pro users, the NPM feature got some improvements: you can now set the NPM tag (instead of defaulting to latest), so you may have npm install yourthing@beta, for example. You can also set extra fields into the package.json, which is specially relevant for the aforementioned MCP feature.

Example:

.goreleaser.yaml

npms:
 - name: "@foo/bar"
 extra:
 mcpName: "io.github.foo/bar"

NPM documentation.

Finally, you can use the fields from the global metadata in your templates, e.g.:

.goreleaser.yaml

metadata:
 description: Foo bar zaz
dockers_v2:
 - images:
 - "ghcr.io/foo/bar"
 labels:
 "org.opencontainers.image.description": "{{.Metadata.Description}}"

Dockers v2

We continue investing in the dockers_v2 feature, and since v2.13.0 we made a lot of improvements:

allow linux/arm/v5
allow to disable SBOMs
allow to template the sbom field
allow to disable a configuration
properly handle --split (on Pro)
respect monorepo.dir (on Pro)
properly set manifest annotations
properly support PyWheel
improve error handling
warning if buildx driver is unknown/unsupported
check buildx driver on goreleaser healthcheck

Other highlights

aur: AUR will now use ${pkgver} in the URLs to generate smaller diffs
aur: allows pre-release versions
announce: Discourse announcer
homebrew_casks: Allow to template 'hooks
signs and docker_signs: allow to template output
homebrew_casks: set more than one binary
ko: Ko can now use a local base image
sbom: make --enrich=all a default flag
makeself: properly handle binary and script names
npm: properly handle HTTP/HTTPS proxies
npm: properly handle run.js exit codes
announce: fix user agent
jsonschema: properly mark fields deprecated
builds/go: only add .h file if it exists
github: better handle GitHub enterprise URLs

Other news

GoReleaser now has ~15.3k stars and 450 contributors! Thanks, everyone!
We often discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.
The GoReleaser Action had a new release, check it out

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries from GitHub:

Install v2.13.0 (OSS) v2.13.0 (Pro)

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Get the Pro license Sponsor the project

Upgrading to Cosign v3

Wed, 05 Nov 2025 00:00:00 +0000

Cosign v3 streamlined its signing workflow by introducing the --bundle flag, replacing the previous approach that required separate certificate and signature files.

What Changed

Previously, signing artifacts with cosign required managing two separate outputs:

A .pem certificate file via --output-certificate
A .sig signature file via --output-signature

Now, the --bundle flag combines both into a single .sigstore.json file, simplifying both signing and verification workflows.

Updating Your GoReleaser Configuration

Here’s how to update your .goreleaser.yaml:

# https://goreleaser.com/customization/sign
signs:
 - cmd: cosign
- certificate: "${artifact}.pem"
+ signature: "${artifact}.sigstore.json"
 args:
 - sign-blob
- - "--output-certificate=${certificate}"
- - "--output-signature=${signature}"
+ - "--bundle=${signature}"
 - "${artifact}"
 - "--yes"
 artifacts: checksum

The key changes:

Remove the certificate field
Update signature to use .sigstore.json extension
Replace --output-certificate and --output-signature flags with a single --bundle flag

Verifying Signatures

Verification is now simpler too. Instead of:

cosign verify-blob \
 --certificate artifact.pem \
 --signature artifact.sig \
 artifact

You now just need:

cosign verify-blob \
 --bundle artifact.sigstore.json \
 artifact

Try It Out

Check out the complete working example at github.com/goreleaser/example-secure to see the new bundle-based signing in action.

This change reduces complexity and makes artifact signing more straightforward for everyone.

For more details, see goreleaser/goreleaser#6195.

Announcing GoReleaser v2.12

Sun, 03 Aug 2025 00:00:00 +0000

This version introduces the new version of the Docker integration, Docker image attestation, Makeself packaging support, Go 1.25, and much more!

Docker v2

The dockers feature in GoReleaser is rather old: it’s from a time before multi-architecture Docker images (manifests). Its configuration is also very verbose and repetitive.

These were problems we were aiming to solve for a while, and after a lot of discussion, we arrived at what I think is a good solution.

It’ll be in alpha stage for a while, and you can use it as dockers_v2 in your configuration.

Once we’re set on the API, we’ll deprecate dockers and docker_manifests.

Eventually, when we launch GoReleaser v3, the old features will be removed, and dockers_v2 will simply be dockers.

That all being said, let’s dive in!

How it works

Basically, we’ll always use docker buildx to build the manifest. This means:

no more dockers + docker_manifests wiring
no more tags with the architecture in them (i.e. no more intermediate images)
no more docker image configuration repetition

Depending on how familiar you are with Docker manifests, you may be asking “how does this work when I do a local build with --snapshot?” - and that’s a great question! Manifests require us to push the images, so, to avoid doing that in snapshot builds, when the build is a snapshot, GoReleaser will automatically “explode” the build configuration by platform, and build local images with the architecture in the tag. This allows you to still test both the build process and correctness of the images without having to push any images.

How to use it?

A simple configuration would look like this:

.goreleaser.yaml

dockers_v2:
 - images:
 - user/repo
 tags:
 - "{{.Version}}"
 - latest
 platform:
 - linux/amd64
 - linux/arm64

And the Dockerfile might look like so:

Dockerfile

FROM scratch
ARG TARGETPLATFORM
ENTRYPOINT ["/usr/bin/myprogram"]
COPY $TARGETPLATFORM/myprogram /usr/bin/

You can add however many images and tags you want, and GoReleaser will build the combination of all of them. You can also set annotations, labels, Docker flags, etc.

Read the documentation for more information.

Makeself

Makeself allows to create packages that self-extract/run. GoReleaser now supports creating them.

You basically only need to set the script that it’ll run after extracting your binary.

Here’s an example:

.goreleaser.yaml

makeselfs:
 - script: ./run.sh

Your shell script can simply be:

run.sh

#!/bin/sh
./myprogram $*

And it should work. Read the documentation for more information.

Attestations

You can now also more easily attest your Docker images within GitHub actions.

Basically, GoReleaser will now automatically generate ./dist/digests.txt file, which you can then pass to the attest action:

./.github/workflows/release.yaml

# ...
permissions:
 # ...
 # Give the workflow permission to write attestations.
 id-token: write
 attestations: write

jobs:
 release:
 # ...
 steps:
 # ...
 - uses: goreleaser/goreleaser-action@v6
 with:
 # ...
 # After GoReleaser runs, attest all the files in ./dist/checksums.txt:
 - uses: actions/attest@v4
 with:
 subject-checksums: ./dist/checksums.txt
 # After GoReleaser runs, attest all the images in ./dist/digests.txt:
 - uses: actions/attest@v4
 with:
 subject-checksums: ./dist/digests.txt

This will create 2 attestations, one for binaries/archives/etc and another one for your Docker images.

Read the documentation for more information.

Thanks to Brian DeHamer from the GitHub team for the help making this happen!

Smarter semver tag sorting

This feature is exclusively available with GoReleaser Pro.

If you do constant pre-releases, this is for you!

Imagine you have a history like this:

v0.1.0
v0.2.0-beta.1
v0.2.0-beta.2
v0.2.0-beta.3
v0.2.0

And you want to release v0.2.0. Usually, GoReleaser would get v0.2.0-beta.3 as previous version, but that’s likely not what most people would expect (v0.1.0).

Smart semver will ignore pre-release versions in these cases, making the release notes more complete.

To use it, add this to your configuration:

.goreleaser.yaml

git:
 tag_sort: smartsemver

Note

If you were to release v0.2.0-beta.3, though, it would still get v0.2.0-beta.2 as previous version, which I think makes sense.

See the documentation for more details.

Other highlights

pro: create nightly releases as drafts (nightly.draft)
pro: set custom body in pull requests
pro: set the changelog title
pro: commit_author can now be set globally in metadata
builds/bun: allowing more targets
builds/go: updated allowed targets
mcp: can now give instructions to the LLM on how to fix deprecations
templates: add readFile and mustReadFile
upload,artifactory: allow to set password
upload,artifactory: allow templates in username
docker: retry configurations
brew: uses && instead of and
cask: removes conflicts_with (deprecated by Homebrew)

Other news

GoReleaser now has ~15.1k stars and 440 contributors! Thanks, everyone!
We often discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.
The GoReleaser Action had a new release, check it out

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries from GitHub:

Install v2.12.0 (OSS) v2.12.0 (Pro)

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Get the Pro license Sponsor the project

Announcing GoReleaser v2.11

Tue, 08 Jul 2025 00:00:00 +0000

This version consists mostly of improvements to the Homebrew Cask feature introduced in the last release, and in other features.

pro: added republish to Cloudsmiths;
pro: publishers get a output option, which sets the output of the command as a template variable with that name (e.g. output: foo allows you to use {{ .Outputs.foo }});
pro: it will now allow to create nightly releases when there’s no tags in the repository yet;
cask: moved custom_block to the beginning of the Cask, renamed manpage to manpages to better match the Cask API, and added docs on how to make Casks for private repositories;
git: you can now setup commit signing when publishing to a git repository;
ui: the --help now looks a bit better, and we also improved the program output in a few places;
cleanups: made a few improvements on how context cancellation works (i.e. on timeouts or SIGINT), removed the usage of some libraries, and many other smaller changes;

Other news

GoReleaser now has ~14.8k stars and 435 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries from GitHub:

Install v2.11.0 (OSS) v2.11.0 (Pro)

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Get the Pro license Sponsor the project

Announcing GoReleaser v2.10

Sun, 08 Jun 2025 00:00:00 +0000

This version introduces the new Homebrew Casks feature, an experimental MCP server, plus many other small improvements.

Homebrew Casks

Historically, the brews section was kind of a hack. In Homebrew, Formulas are supposed to be used to build something from source, and then install it. We were leveraging it to install something that was already built elsewhere.

But no more! Thanks to the help of Sean Molenaar from the Homebrew team, this version introduces a new homebrew_casks section that does the right thing!

You can follow the migration guide to learn how to adjust your configuration, but, in most cases, you only need to rename brews to homebrew_casks and that’s it.

For instance, GoReleaser’s own configuration:

.goreleaser.yaml

brews:
 - repository:
 owner: goreleaser
 name: homebrew-tap
 directory: Formula
 goarm: "7"
 homepage: https://goreleaser.com
 description: Release engineering, simplified
 license: MIT
 test: |
 system "#{bin}/goreleaser -v"
 conflicts:
 - goreleaser-pro
 extra_install: |-
 bash_completion.install "completions/goreleaser.bash" => "goreleaser"
 zsh_completion.install "completions/goreleaser.zsh" => "_goreleaser"
 fish_completion.install "completions/goreleaser.fish"
 man1.install "manpages/goreleaser.1.gz"

.goreleaser.yaml

homebrew_casks:
 - repository:
 owner: goreleaser
 name: homebrew-tap
 homepage: https://goreleaser.com
 description: Release engineering, simplified
 license: MIT
 conflicts:
 - formula: goreleaser-pro
 - formula: goreleaser
 - cask: goreleaser-pro
 manpage: "manpages/goreleaser.1.gz"
 completions:
 bash: "completions/goreleaser.bash"
 zsh: "completions/goreleaser.zsh"
 fish: "completions/goreleaser.fish"

Caution

Signing and Notarizing

If you don’t currently sign and notarize your binaries, you might also need to add a post install hook to remove the quarantine bit.

All that being said, the old brews section is deprecated and should be removed in our next major (v3, not planned date yet) unless someone finds a big reason not to.

And again, thanks to Sean for all the help and feedback given! You rock!

MCP server

As an experiment, we now ship a MCP server. It doesn’t do a lot - yet, but I think that, as AI grows, it might get more features and become increasingly more useful.

You can use it with any client that supports MCP, for instance, for Claude Desktop, you can add this to your claude_desktop_config.json:

{
 "mcpServers": {
 "goreleaser": {
 "command": "goreleaser",
 "args": [ "mcp" ]
 }
}

Or, with mods (running from main):

mcp-servers:
 goreleaser:
 command: goreleaser
 args:
 - mcp

Or, you can add it to your tool of choice. Basically, just call goreleaser mcp and that’s it.

We’re also very interested in other tools GoReleaser MCP can provide. Feel free to hop in our discussion and give whatever feedback or ideas you have!

Other smaller changes

pro: npms got a url_template field
pro: improved error handling for Cloudsmith
ko: allow to specify the local domain for local registries
nfpm: allows to set RPM’s build host
sbom: templeteable disable field
bun, deno: fixed duplicated build flags
homebrew, nix: support more archive formats

Other news

GoReleaser now has ~14.7k stars and 433 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries from GitHub:

Install v2.10.0 (OSS) v2.10.0 (Pro)

Upgrading with Homebrew

If you installed GoReleaser from our tap, this one time you’ll need to:

brew uninstall goreleaser/tap/goreleaser
brew install --cask goreleaser/tap/goreleaser

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Get the Pro license Sponsor the project

Announcing GoReleaser v2.9

Tue, 29 Apr 2025 00:00:00 +0000

This release introduces support to Python builds through Poetry and UV!

Python builds

You can no build Python packages with UV or Poetry. You can run goreleaser init in your Python project, and it should generate the appropriate .goreleaser.yml for you, but, basically, all you need is this:

.goreleaser.yaml

builds:
 - builder: uv
 buildmode: wheel

You can also change uv to poetry if you want that instead, and you can also add another build instance with buildmode: sdist if you need it.

You can see a full example here, as well as docs for both UV and Poetry.

Other smaller changes

Python builds are the biggest news of this release, but we still put another couple of good improvements in there:

pro: license checks now properly handle canceled subscriptions;
pro: custom publishers can now publish MSIs, DMGs, and SBOMs;
templates: many checksum functions, so you can do things like {{ sha256 .ArtifactPath }};
ko: you can now pass sbomDir to your Ko configurations;
winget: you can now set privacy_url and installation_notes;
fix: GoReleaser will now issue better warnings when your configuration produces many artifacts with the same file path;

Gophercon LATAM

I’ll be speaking at Gophercon LATAM 2025 next week! Come chat if you go, I’ll have stickers! :)

Other news

GoReleaser now has ~14.4k stars and 423 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries from GitHub:

Install v2.9.0 (OSS) v2.9.0 (Pro)

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Get the Pro license Sponsor the project

Announcing GoReleaser v2.8

Wed, 12 Mar 2025 00:00:00 +0000

Happy March! Another release is here with several improvements across the board.

Let’s dig into some of the news!

New Package Repository Features

This feature is exclusively available with GoReleaser Pro.

The Cloudsmith integration now supports multiple distributions.

Learn more.

Publish to NPM

This feature is exclusively available with GoReleaser Pro.

This is a long asked feature: publish your project to NPM.

NPM is great because pretty much every developer has it installed, and some enjoy installing binaries through it.

GoReleaser can generate the package for you, which will, upon install, download and extract the right archive from the release.

You can read more about it here.

Native macOS DMG signing and notarizing

This feature is exclusively available with GoReleaser Pro.

GoReleaser Pro and OSS can already sign and notarize binaries, but DMGs and .apps are a whole different ordeal.

This version adds support to it, and you can read more about it here.

New templating features

This feature is exclusively available with GoReleaser Pro.

.IsMerging: will be true if its the final step of a partial build;
.IsRelease: will be true if its not a snapshot nor a nightly build;
reReplaceAll: allows to use regular expressions to replace parts of the string. More on that below!

You can learn more about it here.

AUR and KO Improvements

Both AUR and AUR Sources now support adding custom install scripts.

Also, you can now use aurs.disable and aur_sources.disable to conditionally disable a particular configuration.

Similarly, you can now also use kos.disable.

Read more about it here, here, and here.

Changelog improvements

Historically, when using the git changeloger, we didn’t had many options. We would use the oneline format, and split on the first space, so we got both the commit SHA and the message.

In this version, we started using a custom format, which allowed us to:

properly handle commit abbrevs when using custom formats
customize format when using use: git, including adding author name and email
properly handle filters when the format doesn’t have a leading SHA

With the usage of the newly added reReplaceAll function, you may also do things like this:

.goreleaser.yaml

changelog:
 format: '{{ reReplaceAll "(.*) \\(#(.*)\\)" .Message "$1 [#$1](https://my.custom.tracker/issues/$2)" }}'

Which I think is pretty neat. :)

Deprecations

To make options more alike, archives.builds, nfpms.builds, and snaps.builds have been renamed to archives.ids, nfpms.ids, and snaps.ids.

All active deprecation warnings.

Other smaller changes

pro: goreleaser healthcheck will now properly check MSI and DMG dependencies;
pro: goreleaser r --nightly will now work on a repository with no tags;
pro: DMG on macOS will now use ULMO instead of UDBZ - this should yield smaller .dmg files. Compatible with macOS 10.15+ (from 2019);
archive: when running the pipeline on Windows, set the binaries as executable inside the archives;
docker: retry manifest push if digest don’t match - this seems to be an out-of-sync issue with the registry;
nfpm: properly handle skips of single configurations;

Other news

GoReleaser now has ~14.4k stars and 423 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries from GitHub:

Install v2.8.0 (OSS) v2.8.0 (Pro)

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Get the Pro license Sponsor the project

Announcing GoReleaser v2.7

Mon, 10 Feb 2025 00:00:00 +0000

Happy February! Another release is here with several improvements across the board.

Let’s dig into some of the news!

Simplified versioning

This feature is exclusively available with GoReleaser Pro.

GoReleaser Pro always had a -pro suffix in its versions. This doesn’t make a lot of sense, as the project is already called goreleaser-pro. So now, GoReleaser v2.7 is tagged v2.7.0 - without the -pro suffix.

Our GitHub Action should handle it seamlessly.

Regardless, let us know if you find any issues.

Warning

Make sure to use the latest action version.

MSI Improvements

This feature is exclusively available with GoReleaser Pro.

The MSI builder got some nice improvements in this release:

Added support for ARM64 architectures
Added support for WiX 4+

New Package Repository Features

This feature is exclusively available with GoReleaser Pro.

Package repository integrations got better:

Added support for Fury APK packages
Added Cloudsmith component/channel support
Improved DockerHub integration with description from global metadata

Conditional Hooks

This feature is exclusively available with GoReleaser Pro.

You can now use conditions in hooks with the new if property, allowing more granular control over when hooks should run.

Other Highlights

new: allow OSS to use Pro configurations when --snapshot is set
new: artifactories.skip
build: fixed ppc64le builds
build: improved logging
improved error handling, specially around build errors

As always, the release includes numerous dependency updates, documentation improvements, and general housekeeping changes.

Other news

GoReleaser now has ~14.2k stars and 419 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Announcing GoReleaser v2.6

Tue, 21 Jan 2025 00:00:00 +0000

Happy new year! The first release of the year is here!

Let’s dig into some of the news!

Bun and Deno

This release adds support for both Bun and Deno! You can run goreleaser init in an existing project, and it should figure it out from there!

If you want to see it in action, check out example-bun and example-deno.

We aim to add support to more builders/languages in the coming releases. You can join the discussion in our Discord.

Use AI to increment your release notes

This feature is exclusively available with GoReleaser Pro.

You can now use ChatGPT, Anthropic, and Ollama to increment/change your release notes.

The default prompt instructs the assistant to write a introduction chapter and to join dependency update commits, but I recommend you roll your own.

Usage is fairly simple, too:

.goreleaser.yaml

changelog:
 ai:
 use: anthropic
 prompt:
 from_file:
 path: ./prompt.md

You can read the full docs here.

New macOS App Bundle capatilities

This feature is exclusively available with GoReleaser Pro.

On macOS App Bundles, you may now set extra files (and templated extra files), and use that to override your Info.plist (which was previously generated by GoReleaser and impossible to replace):

.goreleaser.yaml

app_bundles:
 - extra_files:
 - src: ./icon.png
 dst: Contents/Resources/icon.png
 templated_extra_files:
 - src: ./Info.plist
 dst: Contents/Info.plist

New macOS signing features

The native macOS signing now allows you to set the entitlements:

.goreleaser.yaml

notarize:
 macos:
 - sign:
 entitlements: ./entitlements.xml

New MSI features

The MSI now allows to setextensions:

.goreleaser.yaml

msi:
 - extensions:
 - '{{ if eq .Runtime.Goos "windows" }}WixUIExtension{{ end }}'
 - "WixUtilExtension"

Archive multiple formats

Instead of repeating the archive section for each format, you may now set formats: [ all the formats you want ]. Incidentally, you may also use format_override to set multiple formats.

A use case for this is if you want to release as tar.gz for all OSs, but also want a zip for Windows. You can then do:

.goreleaser.yaml

archives:
 - formats:
 - tar.gz
 format_overrides:
 - goos: windows
 formats:
 - zip
 - tar.gz

Announce enabled

All the announcers enabled fields are now templateable.

Example usage:

.goreleaser.yaml

announce:
 mastodon:
 enabled: "{{ eq .Patch 0 }}" # only if new feature release!
 message_template: "#GoReleaser {{ .Tag }} is out! Check it out: https://github.com/goreleaser/goreleaser/releases/tag/{{ .Tag }}"
 server: https://fosstodon.org

Nightlies for real

Our own nightly builds were being built weekly. Now they are, in fact, running every night! This should help users play with new features earlier.

Other Highlights

Most of the work in this release was around multi-language support, but nevertheless, we have a few other news:

New features

new: .Format template variable in archives (only on Pro)
new: Allow to template release.make_latest
new: Set the mtime in nfpms
new: We made a maintainers page. Make sure to check it out!
deprecations: we deprecated archives.format and archives.format_overrides.format in favor of archives.formats and archives.format_overrides.formats, respectively. Details

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~14.1k stars and 417 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Using GoReleaser and GitHub Actions to release Rust and Zig projects

Thu, 02 Jan 2025 00:00:00 +0000

GoReleaser v2.5 is out with Rust and Zig support - let’s explore how we can use it!

What is GoReleaser?

I’m aware that GoReleaser is kind of famous in the Go community, and I’m also aware most Zig and Rust developers might have never heard of it.

This is an attempt to fix it a little bit.

GoReleaser is a release automation tool. Up until recently, it only supported Go, but now we’re slowly adding more languages to it, Zig and Rust being in the first batch.

Some of the key features are:

Cross-compilation and packaging for multiple platforms
Automatic changelog generation from Git history
Creation of Linux packages (deb, rpm, apk)
Docker image building and publishing
Artifact signing and SBOM generation
Integration with package managers (Homebrew, Scoop, Winget, etc.)
GitHub/GitLab/Gitea releases automation

It handles complex release workflows through a single YAML file, eliminating the need to maintain separate release scripts/complex workflows and ensuring consistent releases.

Goal

By the end of this, you should have GitHub action do all the work of releasing your binaries, universal binaries, including packaging, Docker images, signing, and more.

Assumptions

You either have a Zig project that can be cross-compiled with zig build, or a Rust project that can be cross-compiled with cargo zigbuild
Your project is hosted on GitHub
You have [GoReleaser installed][install]¹

Getting started

Into your project root directory, run:

goreleaser init

This should add some entries to your .gitignore, and create a .goreleaser.yaml with builds, archives, changelog and a release footer set up.

You can now run:

goreleaser release --clean --snapshot

And it should complete with no problems.

The build

Whether you are using Zig or Rust, GoReleaser should have set up the configuration file accordingly when you ran goreleaser init.

The main note here is that, with Rust, by default, we’ll use cargo-zigbuild. You can change that to use cross-rs or do more complex stuff, like using goreleaser-rust-cross.

If cargo-zigbuild works for you, though, I’d stay with it, as it is simpler.

Adding stuff

Let’s add some features to our release.

After each step, you should be able to run goreleaser release --clean --snapshot like we did earlier to verify if it works.

Universal binaries

Universal binaries (also known as fat binaries) is a format introduced in macOS a while ago, when Apple migrated from PPC to Intel. It has become common again recently with the introduction of their ARM chips. It’s pretty much both binaries glued together plus a special header.

Luckily, you don’t really need to know any of that, GoReleaser handles it for us. You can enable it by adding this to your .goreleaser.yml:

.goreleaser.yaml

# ...
universal_binaries:
 - replace: true

That’s it!

There are some customization options available, you can see documentation here.

Linux packages

GoReleaser uses nFPM to generate Linux packages for many formats. You can enable it by adding this to your .goreleaser.yml:

.goreleaser.yaml

# ...
nfpms:
 - file_name_template: "{{ .ConventionalFileName }}" # optional, better file names
 formats:
 - deb
 - apk
 - rpm

There you can add more things, for example the maintainer, license, more files, etc. See documentation here.

Sign with cosign

It’s generally a good idea to sign your artifacts. I usually sign the checksums file, as it ensures that the checksums didn’t change, and so you can check that the artifacts haven’t changed either.

You can use GPG, but generally, cosign is way easier! It even allows keyless signing, which uses either GitHub actions, or asks you to login to sign.

It works pretty great.

You can enable it by adding this to your .goreleaser.yml:

.goreleaser.yaml

# ...
signs:
 - cmd: cosign
 certificate: "${artifact}.pem"
 artifacts: checksum
 args:
 - sign-blob
 - "--output-certificate=${certificate}"
 - "--output-signature=${signature}"
 - "${artifact}"
 - "--yes"

The signing feature in GoReleaser allows for many other options, see documentation here for more details.

This will require you to have cosign installed and available in your $PATH.

Software Bill of Materials (SBOM)

SBOM is a formal record that lists all software components, dependencies, and their relationships. It’s mainly used to assess risk in a software supply chain.

By default, GoReleaser will use syft for it. You can enable it by adding the following to your .goreleaser.yml:

.goreleaser.yaml

# ...
sboms:
 - artifacts: archive

Generally speaking you can tune this to use any other tool you want, see documentation here for more details.

This will require you to have syft installed and available in your $PATH.

Homebrew Tap

Homebrew is commonly used on macOS to install software. GoReleaser supports homebrew taps, and the taps generated also work on Linux.

You can enable it by adding this to your .goreleaser.yml:

.goreleaser.yaml

# ...
brews:
 - repository:
 owner: YOUR-USERNAME
 name: YOUR-TAP
 token: "{{ .Env.GH_PAT }}"
 directory: Formula

A couple of notes here:

You’ll need a GH_PAT in your actions workflow later, as usually taps are published in their own repositories
You’ll need to create the repository beforehand. It can be an empty repository. See some examples.

There you can add more things, for example the maintainer, license, more files, etc. See documentation here.

Docker Images

We can also make GoReleaser create, push, and sign Docker images and manifests.

Before proceeding, we need a Dockerfile:

Dockerfile

FROM ubuntu
COPY example /usr/bin/example
ENTRYPOINT [ "/usr/bin/example" ]

Notice that we don’t build anything here. GoReleaser will setup the context, so we have the previously built binary available, and can then simply copy it!

Now, we have mainly two options: if you want to push only the Linux/amd64 image, you can simply add something like this to your configuration:

.goreleaser.yaml

# ...
dockers:
 - image_templates:
 - "ghcr.io/YOUR_USER/YOUR_REPO:{{ .Tag }}"
 - "ghcr.io/YOUR_USER/YOUR_REPO:latest"

Note: using GHCR will requires us to log in and have the right workflow permissions on the GitHub Action.

Now, if we want a manifest with multiple platforms, we need a little more setting up:

.goreleaser.yaml

# ...
dockers:
 - image_templates:
 - "ghcr.io/YOUR_USER/YOUR_REPO:{{ .Tag }}-arm64"
 goarch: arm64
 use: buildx
 build_flag_templates:
 # note that this changes according to goarch
 - "--platform=linux/arm64"
 - image_templates:
 - "ghcr.io/YOUR_USER/YOUR_REPO:{{ .Tag }}-amd64"
 goarch: amd64
 use: buildx
 build_flag_templates:
 # note that this changes according to goarch
 - "--platform=linux/amd64"

This will build 2 images (and push them later on), which we can then combine in a single manifest like so:

.goreleaser.yaml

# ...
docker_manifests:
 - name_template: "ghcr.io/YOUR_USER/YOUR_REPO:{{ .Tag }}"
 image_templates:
 - "ghcr.io/YOUR_USER/YOUR_REPO:{{ .Tag }}-arm64"
 - "ghcr.io/YOUR_USER/YOUR_REPO:{{ .Tag }}-amd64"

Finally, we can also sign the manifests:

.goreleaser.yaml

# ...
docker_signs:
 - cmd: cosign
 artifacts: manifests
 args:
 - "sign"
 - "${artifact}"
 - "--yes"

Note: the manifest will only be built in “production” builds, e.g. without the --snapshot flag.

Additional options are available on everything we used here, take a look at the documentation for each feature:

This will require you to have docker and cosign installed and available in your $PATH.

GitHub Actions

Now, you probably don’t want to run all this locally on every release! Let’s use GitHub Actions - but any CI should do in most cases².

To enable this, we can simply add something like this to .github/workflows/goreleaser.yml:

.github/workflows/goreleaser.yaml

name: goreleaser

on:
 push:
 # run only against tags
 tags:
 - "*"

# You might not need all of this...
permissions:
 contents: write
 packages: write
 issues: write
 id-token: write

jobs:
 goreleaser:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 with:
 fetch-depth: 0

 # we'll need this for both 'zig build' and 'cargo zigbuild'
 - uses: mlugg/setup-zig@v1

 # only needed if using signing
 - uses: sigstore/cosign-installer@v3.7.0

 # only needed if using SBOMs
 - uses: anchore/sbom-action/download-syft@v0.17.9

 # only needed if using docker
 - uses: docker/setup-qemu-action@v3
 - uses: docker/setup-buildx-action@v3
 - uses: docker/login-action@v3
 with:
 registry: ghcr.io
 username: ${{ github.repository_owner }}
 password: ${{ secrets.GITHUB_TOKEN }}

 - uses: goreleaser/goreleaser-action@v6
 with:
 # either 'goreleaser' (default) or 'goreleaser-pro'
 distribution: goreleaser
 # 'latest', 'nightly', or a semver
 version: "~> v2"
 args: release --clean
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 # used to push the homebrew tap
 GH_PAT: ${{ secrets.GH_PAT }}
 # Your GoReleaser Pro key.
 # Only needed if you're using the 'goreleaser-pro' distribution.
 # GORELEASER_KEY: ${{ secrets.GORELEASER_KEY }}

Once that’s done, you can push a new tag and watch the magic happen!

If you fancy building the release artifacts on every release, you can set up auto snapshotting as well, check this file out for more details.

This is cool! What else can it do?

Glad you enjoy it and glad you asked!

Here’s an incomplete list:

Nightly builds
S3/GCS/etc
Winget, AUR³, NUR⁴, Scoop, Krew
macOS sign and notarize
DMG
MSI
Chocolatey
macOS App Bundles
and many more!

Note: some features deemed “enterprise-ish” require the Pro version, which is paid.

Troubleshooting

Some things that can help you verify your configuration:

# Most features allow to be skipped, which can help speed up your local iterations.
# See the available options with `goreleaser release --help`.
goreleaser release --clean --snapshot --skip=[feature1,feature2]

# Verify if you have all the needed binaries in your $PATH:
goreleaser healthcheck

# Check if your configuration is valid (only check syntax):
goreleaser check

# If you only want to build the binaries, the build sub command might help!
goreleaser build

If the build itself fails, it’s always good to check if it works outside GoReleaser, e.g. run cargo zigbuild --target the-one-that-failed and see what happens.

Closing words

I hope this clarifies a bit what GoReleaser can do!

If you want to check the examples live, they’re available here and here.

Also worth noting that Bun and Deno support are in the works, and we’ll probably add Python soon as well, maybe all for v2.6. Stay tuned!

Thanks for reading!

Versions used

For reference, these are the tools and versions used:

Tool	Version
goreleaser	2.5.1
zig	0.13.0
cargo	1.83.0
rustc	1.83.0
cargo zigbuild	0.19.7
cosign	2.4.1
syft	1.18.1
docker	27.3.1
docker buildx	0.18.0

Cross-posted from carlosbecker.com.

Some things we’ll use were not working on v2.5.0, but are fixed in v2.5.1. Make sure to install that version (or newer). ↩︎
Most CIs do not support the Keyless Signing mechanism we are using with cosign, so that’s probably the main consideration. ↩︎
Arch User Repositories ↩︎
Nix User Repositories ↩︎

Announcing GoReleaser v2.5 - multi languages, 8th anniversary edition

Sun, 15 Dec 2024 00:00:00 +0000

Merry Christmas - the last release of 2024 is here!

This is hopefully the last big release of the year, and I think it’s a good one!

Rust and Zig joined the party!

The biggest highlight of this release surely is the start of the multi-language support!

Over the years, more than once, I’ve seen comments saying something along the lines of “I would love something like GoReleaser for ”.

In fact, there are things like jReleaser, cargo-dist, rustreleaser, and probably others, that are built based on some of GoReleaser’s ideas. As far as I know, all these projects are good and nice, and in fact, many years ago, I had already refactored some of GoReleaser’s codebase thinking about adding more languages to it.

My idea at the time was to support plugins, so users could provide their own builders. I quickly realized, though, that Go plugin support is less than ideal, so I kind of give that idea up, but left the refactor in there (and almost undo it a few months ago).

But I digress… GoReleaser now officially, albeit in alpha, supports both Rust and Zig!

You can use goreleaser init to create a configuration file and go from there. It should detect that you are in a Rust project (if it has a Cargo.toml) file or Zig project (if you have a build.zig file) automatically and initialize accordingly.

But, in summary, you can do something like:

.goreleaser.yaml

builds:
 - builder: rust # or zig

And it should already do something, with hopefully good defaults.

To add a few details: the Rust builder uses the excellent cargo-zigbuild by default, but you can change the configuration to use cross as well.

On the other hand, the Zig builder uses its native zig build command.

In both cases, we’re for now limiting to some targets that on our tests seemed to work. If you disagree, please open an issue or hop in our Discord.

We also have example repositories for both: example-rust, example-zig.

Finally, Vedant made goreleaser-rust-cross, a Docker image with the toolchains needed to cross compile Rust, which might be useful for some of you!

If you work with Zig and/or Rust, we’ll be more than happy to have your feedback and help improving all this!

Thanks

This feature was quite a big undertaking, and while I’m sure it’s not perfect, it is something.

I want to thank Raphael Amorim for giving me the incentive I needed and for helping reviewing it!

Also, Vedant for helping reviewing and asking many questions, which helped shape the Rust integration quite a bit.

Finally, I want to thank the Go community, for using GoReleaser all these years, and the Rust and Zig community for being (seemingly) open to the idea!

What’s next?

Probably more languages! Join our Discord and help prioritize and shape how they’ll work. I already created a new discussion on GitHub to help prioritize languages as well. You are absolutely invited to chime in!

Once we stabilize all that, probably another major release refactoring some things that are still too Go-centric (like the usage of goos nomenclature everywhere).

Testing on Windows

This is not technically in this release, but was added in v2.4.6 and is pretty big/good news: we now run GoReleaser tests on Windows as well.

This should help reducing Windows-specific bugs - in fact, while doing that, I already fixed some.

It was pretty painful to do this using VMs, so, if you use Windows and want to help, please feel very welcome to! :)

8 years old!

December 21th marks the day of the very first GoReleaser commit. The first release came a couple of days later, on the 29th.

When I first started this, I had no idea it would last this long.

It has been a long, fun, and honoring ride! I met a lot of awesome people through OpenSource, had a lot of opportunities I wouldn’t have otherwise, and, maybe more importantly, learned a lot!

Thank you all for being a part of it!

Site and Logo

I experimented with some new logo designs, trying to make it less go-focused.

Our current logo is very good, in my opinion: it is playful, recognizable, looks cute, all that good stuff.

Still, I tried some ideas to see how they would look like, but I didn’t think any of them would live up to the original one (you’ve seen one of them in the beginning of the post), so, I’ll keep it as is for now.

Our homepage got a relatively new look, though. We reorganized some things, improved others, changed some colors, and, overall, I think it looks better.

All the artwork GoReleaser uses is made by Carine Becker, and is available here.

Other Highlights

Most of the work in this release was around multi-language support, but nevertheless, we have a few other news:

new: publishers.if (only on Pro)
new: AUR Sources integration
new: webhooks expected_status_codes
new: KOs can now build one time but publish to multiple registries¹
new: allow editing existent draft release on GitHub
fix: we were using Homebrew’s on_arm and on_intel constructs, but they shouldn’t be used with url in it. So we changed back to checking Hardware::CPU. Details
deprecations: we deprecated builds.gobinary in favor of builds.tool to be more language-agnostic, and kos.registry in favor of kos.registries to support multiple registries. Details

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~14k stars and 413 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

This is accomplished by using crane to copy from one registry to the others. Crane was already included as a dependency, so you don’t need to install anything for it to work. ↩︎

Announcing GoReleaser v2.4

Sat, 02 Nov 2024 00:00:00 +0000

New release coming in hot!

new: create macOS app bundles. Initially they are only usable with dmgs, more uses might be added in the future. (only on pro) Example:
.goreleaser.yaml
```
app_bundles:
 - bundle: com.goreleaser.goreleaser
 icon: www/docs/static/goreleaser.icns
 if: '{{eq .Arch "all"}}'
dmg:
 - name: goreleaser
 use: appbundle
```
DMG with GoReleaser Pro's App Bundle.
new: nfpms and dmgs get an if field, which allows to further filter artifacts. (only on pro)
new: dmgs get an templated_extra_files field. (only on pro)
new: kos gets support for setting annotations and user.
new: support for GO386, GOARM64, GOMIPS64, GORISCV64, and GOPPC64, as well as new template variables for each of them.
new: experimental change of default GOARM to 7 instead of 6.
new: we are testing using Dagger to run our test pipeline. Thanks to the Dagger team for working on it, especially Kyle, Lev, and Marcos.

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~13.7k stars and 409 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Announcing GoReleaser v2.3

Thu, 12 Sep 2024 00:00:00 +0000

Another month, another minor release full of improvements!

new: blobs gets an if field, which allows to further filter artifacts. One cool use case is split checksums and then uploading only the checksums of the files being uploaded, instead of all of them (only on pro)
new: on the same token, checksums will now have an ID if they are being split (only on pro)
new: .ArtifactID template variable (only on pro)
new: builds.skip and builds.no_unique_dist_dir are now templateable
new: .IsSingleTarget template variable
ko: KO pipe now runs on snapshots as well
github: fixed a possible nil in error handling
build: --single-target is now more specific, and will build only the exact match
build: some improvements when target is wasm
brew: brews[*].dependencies[*].os and brews[*].dependencies[*].version were not being used

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~13.6k stars and 403 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Announcing GoReleaser v2.2

Wed, 14 Aug 2024 00:00:00 +0000

Another month, another minor release full of improvements!

new: binary_signs allows to sign binaries before archiving them
new: signs.if, binary_signs.if, docker_signs.if allows to further filter artifacts using template expressions (only on pro)
new: list and in template functions
new: --skip=report-sizes
new: --clean will now remove ./dist before checking if the current git state
gitlab: fixed release file URL
templates: fixed isEnvSet and envOrDefault not working in some cases
ko: clarified an error message, also cyclonedx and go.version-m support was removed from upstream, so we removed it here too
deprecated: nightly.name_template -> nightly.version_template
deprecated: snapshot.name_template -> snapshot.version_template

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~13.5k stars and 398 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Announcing GoReleaser v2.1

Sat, 13 Jul 2024 00:00:00 +0000

Winter is here (in the South America)! Let’s see whats new!

Highlights

new: before publish hooks (only on pro)
new: cloudsmith publisher (only on pro)
new: global metadata (only on pro)
new: templated_extra_files support in artifactory and http publishers (only on pro)
new: allow to upload only the extra_files in the blob publisher
archives: support for the tar.zst archiving format
archives: --skip=archive
build: support GOCACHEPROG
nfpm: support for the ipk package format
nfpm: build packages for termux
notary: allow to sign macOS binaries without notarizing them
github: better handle discussion creation, drafts, etc
gitlab: better handle CI_JOB_TOKEN and unavailable APIs
changelog: respect longer abbrev
snapcraft: better handle concurrent builds
docs: improved home and install pages

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~13.4k stars and 396 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Announcing GoReleaser v2

Tue, 04 Jun 2024 00:00:00 +0000

The new major version of GoReleaser is here!

I first launched GoReleaser v1.0.0 in November 2021 - 2.5 years ago!

The main reason for this is that so I can clean up old deprecated options, and cleaning these old things makes it easier to add new things.

A couple of months ago I published a post explaining how GoReleaser’s versioning will work from now on. You can read it here.

So, after two and a half years, it’s beyond time for v2 to happen, don’t you think?

Highlights

GoReleaser v2 is basically the same as the GoReleaser v1.26.2 - the latest v1. The differences between them should be only the removal of deprecated options.

goreleaser –version

All that being said, we do have a lot of new features since the first v1. Here’s an incomplete list with some of my favorites:

Allow to template entire files and use them in release/archives/etc (Pro)
Allow publishing of Nix, Brew, etc across SCMs (Pro)
Added the changelog command and changelog sub-grouping (Pro)
Split & merge releases (release --prepare and continue) (Pro)
Added SBOM creation support
Support Keyless signing with Cosign
Arch User Repository Support (aka AUR)
Added support for GOAMD64 and WASI
Support creating Chocolatey packages
Ko support
Added the healthcheck command
Added more announcers: HTTP, Bluesky, Mastodon, etc
Allow to compress binaries with upx
Added Nix User Repository support (aka NUR)
Added Winget support
Allow Homebrew, Krew, Scoop, Winget, etc to open pull requests
Added support for DMG creation
Added support for MSI creation
Added macOS binaries notarization and signing
A whole lot of improvements regarding templates: new variables, new fields, new functions. 😎

Upgrading

If you keep up with the deprecation notices, it’s likely you don’t need to do anything.

If you don’t, that’s fine too! Let’s figure it out together! You can start by running the following commands:

goreleaser check # using the latest v1
rm -rf ./dist/
grep -iR '\--rm-dist' .
grep -iR '\--skip-' .
grep -iR '\--debug' .

Extra tip: You can also look into your last release logs if they are still there, and fix the deprecation warnings based on it.

Fix any occurrences following this, then, upgrade goreleaser to v2 using the method you used to install v1, and run:

goreleaser check # using latest v2

It should only warn you about the version header in the configuration file, which you can fix by adding version: 2 to it.

Then, you should be ready to use GoReleaser v2! You can build a snapshot with:

goreleaser release --snapshot --clean

GitHub Action

If you use our GitHub Action, the latest version (v6.0.0) should use ~> v2 by default if your version option is either empty or latest.

I recommend you update it:

.github/workflows/release.yml

# ...
jobs:
 goreleaser:
 # ...
 - uses: goreleaser/goreleaser-action@v6
 with:
 distribution: goreleaser # or 'goreleaser-pro'
 version: "~> v2" # or 'latest', 'nightly', semver
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 # GORELEASER_KEY: ${{ secrets.GORELEASER_KEY }} # if using goreleaser-pro

Other news

GoReleaser now has ~13.2k stars and 394 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. You are invited to join the conversation!
goreleaser-action@v6 was also released, now defaults to version: '~> v2' instead of latest.

That’s all for today!

We start working on v2.1 now, and it should be released soon-ish. 👌

Happy releasing! 🚀

Announcing GoReleaser v1.26 - The last v1, probably

Sat, 11 May 2024 00:00:00 +0000

Happy mother’s day!

This will be probably the last minor v1 release of GoReleaser. V2 will not be a big update, rather, it’ll be the same as v1.26, but removing all the deprecated stuff.

That said, let’s see what’s new on this version!

Highlights

new: macOS binaries notarization
new: Publish Homebrew, NUR, Winget, and others, across SCMs (only on Pro)
fury: Retry uploads
continue: Fixed goreleaser continue --merge when running with --snapshot
announce: BlueSky support
archive: Create .tar.zst archives
changelog: Allow to customize the changelog format
checksum: Support Blake2 and SHA-3
release: Added --draft to goreleaser release
gitea: Support changelog
gitlab: Support opening Merge Requests
build: Always log go build outputs
tmpl: Added isEnvSet
homebrew: Updated to use on_arm and on_intel
blob: Allow to skipping the configuration of the Content-Disposition

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~13.1k stars and 380 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.
In preparation for v2, the v5.1.0 of our GitHub Action now defaults to version: '~> v1' instead of latest. This should help prevent unwanted breaking changes. More details.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Announcing GoReleaser v1.25 - Easter edition

Tue, 02 Apr 2024 00:00:00 +0000

Happy Easter!

The second release of 2024 is here! It’s the result of 2 months of work by me and many contributors, aiming on releasing a v2 soon.

Highlights

new: automatically update the description/readme on Docker Hub (only on Pro)
new: added goreleaser verify-license command (only on Pro)
archives: allow to skip archiving certain GOOS by using none in format_overrides
dmg: fix packaging when binary name contains a directory
msi: fix packaging when binary name contains a directory
homebrew: allow to set headers in an URL
homebrew: sync fork before opening PR
krew: sync fork before opening PR
nix: sync fork before opening PR
scoop: sync fork before opening PR
winget: sync fork before opening PR
nix: update valid licenses with upstream
nfpm: signing passphrase improvements, support for compression, fieldsn and predepends on debs
git: retry clone if possible
release: mark release as a draft, upload all artifacts, then publish it
release: allow to delete previously existing artifacts
checksums: allow to create one checksum file for each published artifact
config: look into .config/goreleaser.ya?ml by default
build: support netbsd/arm64
release: support project ID in GitLab
build: support directory in gomod
deprecations: a lot of deprecations, working towards making the configuration file more consistent. Details

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~12.9k stars and 380 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Announcing GoReleaser v1.24 - the first of 2024

Mon, 05 Feb 2024 00:00:00 +0000

Happy new year! The first release of 2024 is here!

Highlights

security: goreleaser would log environment variables in some configurations when run with --verbose. Note that we only recommend using the --verbose flag locally, to debug possible issues. CVE-2024-23840
new: create DMG images (with hdutil/mkisofs) (only on Pro)
new: create MSI installers (with wix/msitools) (only on Pro)
git: options to ignore tag prefixes (only on Pro)
blog: we fully migrated our blog from Medium to mkdocs
blob: ACLs, cache control, and content disposition
nfpm: add libraries to packages
artifactory: allow to publish source archives
brew: improve handling of single OS
nix: improved generated derivations, use stdenvNoCC by default
templates: new fields added, .GitTreeState, .IsGitClean, .Format
jsonschema: we now validate our jsonschema every time it changes to make sure it is still valid
deprecations: we deprecated some options in the changelog and blobs sections. Details

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~12.6k stars and 370 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by reporting issues, contributing features, documentation improvements, and bug fixes. You can also sponsor the project, or get a GoReleaser Pro license.

Announcing GoReleaser v1.23 - the last of 2023

Tue, 26 Dec 2023 00:00:00 +0000

The yearly Christmas edition, and the last release of 2023. This release contains mostly small improvements and bug fixes.

Highlights

nix: validate license to prevent generating invalid derivations
nix: make sure zip is included if one of the archives is a zip file
winget: support archives.format: binary
homebrew: dependencies can be added to specific OSes
homebrew: support tar.xz
aur: support archives.wrap_in_directory
aur: support multiple packages in the same repository
--single-target is now more consistent
error handling improvements in several places

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~12.4k stars and 366 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by contributing features and bug fixes, or by donating. You may also be interested in buying a GoReleaser Pro license.

You can find out more here.

Announcing GoReleaser v1.22 - steady improvement

Mon, 06 Nov 2023 00:00:00 +0000

Another boring release, with mostly bug fixes and quality-of-life improvements.

Highlights

Several new pipes can be skipped with --skip=pipe, check goreleaser release --help for details
If you have gomod.proxy enabled, GoReleaser will now check if your go.mod has replace directives, and warn you about them on snapshots, and straight out fail on a production build
If you have gomod.proxy enabled and a go.work file with multiple modules, GoReleaser will now properly handle it, using the first module as proxy target
Planning for v2, we added an optional version field to the configuration file
The checksum file will now be sorted by filename, as it should

As always, bug fixes, dependency updates, housekeeping, and documentation updates are included in this release as well.

Other news

GoReleaser now has ~12.3k stars and 356 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by contributing features and bug fixes, or by donating. You may also be interested in buying a GoReleaser Pro license.

You can find out more here.

Stay Calm and SLSA: Generating SLSA Provenance for Your Artifacts with GoReleaser and slsa-github-generator

Wed, 11 Oct 2023 00:00:00 +0000

In an age where software is at the heart of nearly every aspect of our lives, software supply chain security has become paramount. It involves a series of measures and practices aimed at ensuring the reliability and safety of the software we use daily. As cyber threats continue to evolve, the need for robust software supply chain security has never been greater. Organizations must take steps to protect their software development and distribution processes from potential vulnerabilities and attacks.

SLSA provenance, short for Supply Chain Levels for Software Artifacts, is an emerging concept that revolutionizes the way we think about software supply chain security. It offers a comprehensive framework to track the lineage and trustworthiness of software components, thereby enhancing overall security.

The core idea behind SLSA provenance is to create a transparent and auditable trail of every software component’s journey, from its creation to deployment. This ensures that any tampering or unauthorized changes can be quickly identified and mitigated. Software supply chain security and SLSA provenance are intrinsically linked, as the latter serves as a critical tool to bolster the former.

Together, they provide a robust defense against the growing threats posed by malicious actors in the digital realm. In a world where software vulnerabilities can have far-reaching consequences, the adoption of SLSA provenance is a proactive step toward fortifying our software supply chains and making them more resilient to cyberattacks.

GoReleaser takes the ever-growing risks in the realm of software supply chain security incredibly seriously. From the onset of this era of heightened security concerns, GoReleaser has been at the forefront, continuously adding features to safeguard your artifacts against potential software supply chain attacks such as generating an SBOMs, signing your artifacts, and more.

If you want to learn more about the general software supply chain security features supported by GoReleaser, check out our blog post on the topic.

In this blog post, we will explore how GoReleaser can help you generate SLSA provenance for your artifacts and how you can leverage the slsa-github-generator to automate the process.

slsa-github-generator

I would like to start with my favorite quote:

Each of these attacks could have been prevented if there were a way to detect that the delivered artifacts diverged from the expected origin of the software. But until now, generating verifiable information that described where, when, and how software artifacts were produced (information known as provenance) was difficult. This information allows users to trace artifacts verifiably back to the source and develop risk-based policies around what they consume. - Improving software supply chain security with tamper-proof builds

Unfortunately, provenance generation is not widely supported yet but hopefully will be in the future. And this is where the slsa-github-generator comes into play.

Thanks to the SLSA community, they developed a collection of GitHub reusable workflows called slsa-github-generator that can help us with the solving of the problem we mentioned in the quote. It is a powerful tool designed to simplify the process of generating SLSA provenances for your GitHub-hosted projects. It seamlessly integrates with your GitHub repositories, providing an efficient way to enhance the security and trustworthiness of your software supply chain by automatically creating and managing SLSA provenance records.

There are different types of workflows/builders that you can use depending on your needs provided by the slsa-github-generator.

and many more…

Without much further ado, let’s jump right into the demo and see how we can use the slsa-github-generator to generate SLSA provenance for our artifacts.

You can find all the code used in this demo in the goreleaser-example-slsa-provenance repository on GitHub.

We said artifacts a lot, but what are artifacts really? In the context of this blog post, artifacts are the binaries and the container images that GoReleaser generates for your project. If you are familiar enough with GoReleaser -if you are not please refer to the Quick Start guide-, GoReleaser uses a configuration file called .goreleaser.yml to define how to build and release your project. In this file, you can define the artifacts that you want to generate for your project.

Let’s take a look at the .goreleaser.yml file of our demo project:

---
builds:
 - env:
 - CGO_ENABLED=0
 goos:
 - linux
 - windows
 - darwin

kos:
 - repository: ghcr.io/goreleaser/goreleaser-example-slsa-provenance
 tags:
 - "{{.Tag}}"
 - "{{ if not .Prerelease }}latest{{ end }}"
 bare: true
 preserve_import_paths: false
 sbom: none
 platforms:
 - all
 flags:
 - -trimpath
 ldflags:
 - -s -w

I trimmed the file a bit to make it easier to read. As you can see, we are building our binaries for the linux, windows, and darwin operating systems as we defined in the builds section, thanks to the built-in cross-compilation support in Golang. We are also using the kos integration to build a container image for our project. It is a new way to build container images your project using ko. We are also using the ghcr.io/goreleaser/goreleaser-example-slsa-provenance repository to push our container image both with the latest and the {{.Tag}} tag.

If you want to learn more about the ko tool, check out our blog post.

Now that we have a better understanding of what artifacts are and the `.goreleaser.yml’ is, let’s see how we can use the slsa-github-generator to generate SLSA provenance for our artifacts.

Before than that we should talk a little bit about the GitHub Actions platform.

GitHub Actions is an automation and continuous integration/continuous deployment (CI/CD) platform provided by GitHub, which is a widely used web-based platform for version control and collaboration among software developers. GitHub Actions allows you to automate various tasks and workflows in your software development process directly within your GitHub repositories.

To use GitHub Actions, you need to create a workflow file in your repository (under .github/workflows). A workflow file is a YAML file that contains a set of instructions that define the steps of your workflow. You can create a workflow file manually or use a workflow template provided by GitHub. GitHub Actions provides a wide range of workflow templates that you can use to automate various tasks and processes in your software development lifecycle. You can also create your own custom workflow templates to suit your specific needs for better reusability and consistency. This is where reusable workflows comes into play.

GitHub Actions and reusable workflows are powerful tools for streamlining your development process, improving code quality, and ensuring consistent practices across your projects. They provide the flexibility and scalability needed to automate tasks and customize your development workflow to meet the specific needs of your software projects.

It’s important to understand reusable workflows since the slsa-github-generator is mostly about reusable workflows.

Let’s have a first look at the GitHub workflow file that we will use to generate SLSA provenance for our artifacts:

---
binary-provenance:
 needs: [goreleaser]
 permissions:
 actions: read # To read the workflow path.
 id-token: write # To sign the provenance.
 contents: write # To add assets to a release.
 uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
 with:
 base64-subjects: "${{ needs.goreleaser.outputs.hashes }}"
 upload-assets: true # upload to a new release

image-provenance:
 needs: [goreleaser]
 permissions:
 actions: read
 id-token: write
 packages: write
 uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
 with:
 image: ${{ needs.goreleaser.outputs.image }}
 digest: ${{ needs.goreleaser.outputs.digest }}
 registry-username: ${{ github.actor }}
 secrets:
 registry-password: ${{ secrets.GITHUB_TOKEN }} # you should provide registry-password, if you are using private registry like ghcr.io

At the time of writing this 1.9.0 is the latest version of the slsa-github-generator. As you can see, we are using two different reusable workflows to generate SLSA provenance for our artifacts. The first one is the generator_generic_slsa3.yml workflow, which is used to generate SLSA provenance for our binaries. The second one is the generator_container_slsa3.yml workflow, which is used to generate SLSA provenance for our container images.

That’s it, we are done. We can now generate SLSA provenance for our artifacts. Confess, you didn’t expect this task to be so straightforward. 🤣

Let’s continue with explaining them in more detail.

First, as you might have noticed, we are using the needs keyword to define the dependencies of our workflow. In this case, we are saying that our workflow depends on the goreleaser job. This means that our workflow will run after the goreleaser job is completed successfully. This is important because we need the artifacts generated by the goreleaser job to generate SLSA provenance for them.

Next, we are using the permissions keyword to define the permissions of our job. This is a new feature of GitHub Actions that allows you to define the permissions of your workflow. This is important because we need to define the permissions of our workflow to be able to generate SLSA provenance for our artifacts. In this case, we are saying that our workflow needs the read permission to read the workflow path, the write permission to sign the provenance, and the write permission to add assets to a release.

As we mentioned we have to wait until the goreleaser job to be finished before we generate SLSA provenance because we need some output from the goreleaser job to generate SLSA provenance.

We are using the outputs keyword to define the outputs of our job. In this case, we are saying that our workflow needs the hashes output from the goreleaser job. This is important because we need the hashes of our artifacts to generate SLSA provenance for them. We are also saying that our workflow needs the image and the digest output from the goreleaser job. This is important because we need the image and the digest of our container image to generate SLSA provenance for them.

Finally, we are using the with keyword to define the inputs of our job. In this case, we are saying that our workflow needs the hashes, image.name and image.digest output from the goreleaser job.

Let’s have a look at the how we generate these outputs in the goreleaser job:

...
jobs:
 goreleaser:
 outputs:
 hashes: ${{ steps.binary.outputs.hashes }}
 image: ${{ steps.image.outputs.name }}
 digest: ${{ steps.image.outputs.digest }}
 ...

 - name: Generate binary hashes
 id: binary
 env:
 ARTIFACTS: "${{ steps.goreleaser.outputs.artifacts }}"
 run: |
 set -euo pipefail

 checksum_file=$(echo "$ARTIFACTS" | jq -r '.[] | select (.type=="Checksum") | .path')
 echo "hashes=$(cat $checksum_file | base64 -w0)" >> "$GITHUB_OUTPUT"

 - name: Image digest
 id: image
 env:
 ARTIFACTS: "${{ steps.goreleaser.outputs.artifacts }}"
 run: |
 set -euo pipefail
 image_and_digest=$(echo "$ARTIFACTS" | jq -r '.[] | select (.type=="Docker Manifest") | .path')
 image=$(echo "${image_and_digest}" | cut -d'@' -f1 | cut -d':' -f1)
 digest=$(echo "${image_and_digest}" | cut -d'@' -f2)
 echo "name=$image" >> "$GITHUB_OUTPUT"
 echo "digest=$digest" >> "$GITHUB_OUTPUT"
...

For the Generate binary hashes step, we are using the jq tool to parse the artifacts output which is one of the outputs of the goreleaser/goreleaser-action from the goreleaser job and extract the checksum file path. We are then using the base64 tool to encode the checksum file and save it to the hashes output.

In essence, the artifacts output consists of the contents of the artifacts.json file that GoReleaser generates in the dist/ folder, starting from version 1.2, as explained in this v1.2 release. This file contains information regarding the artifacts produced by GoReleaser.

During the process of generating SLSA (Supply Chain Levels for Software Artifacts) provenances for both our binaries and container images, we utilize specific jq operations to extract the necessary information such as the hashes for the binaries and the image and digest of our container image from the artifacts.json file.

At the end of the day, you will be having a successful workflow run like this:

Further Steps

As you can see, generating SLSA provenance for your artifacts with GoReleaser and slsa-github-generator is a straightforward process. You might be asking yourself what’s next? Well, the answer is simple because we added verification steps to our workflow to show you how you can verify the SLSA provenance of your artifacts since they were signed by the slsa-github-generator and uploaded to the transparency log server (Rekor).

...
 - name: Verify assets
 env:
 CHECKSUMS: ${{ needs.goreleaser.outputs.hashes }}
 PROVENANCE: "${{ needs.binary-provenance.outputs.provenance-name }}"
 run: |
 set -euo pipefail
 checksums=$(echo "$CHECKSUMS" | base64 -d)
 while read -r line; do
 fn=$(echo $line | cut -d ' ' -f2)
 echo "Verifying $fn"
 slsa-verifier verify-artifact --provenance-path "$PROVENANCE" \
 --source-uri "github.com/$GITHUB_REPOSITORY" \
 --source-tag "$GITHUB_REF_NAME" \
 "$fn"
 done <<<"$checksums"


 - name: Verify image
 env:
 IMAGE: ${{ needs.goreleaser.outputs.image }}
 DIGEST: ${{ needs.goreleaser.outputs.digest }}
 run: |
 slsa-verifier verify-image "$IMAGE@DIGEST" \
 --source-uri "github.com/$GITHUB_REPOSITORY" \
 --source-tag "$GITHUB_REF_NAME"

slsa-verifier is a tool for verifying SLSA provenance that was generated by CI/CD builders. slsa-verifier verifies the provenance by verifying the cryptographic signatures on provenance to make sure it was created by the expected builder (default to GitHub CI/CD) and the source repository the artifact was built from.

cosign allows developers to sign artifacts with digital signatures, ensuring the authenticity and integrity of the artifacts. It also enables users to verify signatures on artifacts to confirm that they haven’t been tampered with.

Both cosign and slsa-verifier play crucial roles in enhancing the security and trustworthiness of software supply chains, particularly in containerized and cloud-native application development. To get the latest information and updates on these tools, it’s recommended to refer to their respective documentation and GitHub repositories or official websites.

Conclusion

In this blog post, we explored how GoReleaser can help you generate SLSA provenance for your artifacts and how you can leverage the slsa-github-generator to automate the process. We also discussed the importance of software supply chain security and how SLSA provenance can help you enhance the security and trustworthiness of your software supply chain. We hope that this blog post has been helpful in understanding how GoReleaser can help you generate SLSA provenance for your artifacts and how you can leverage the slsa-github-generator to automate the process. If you have any questions or feedback, please feel free to reach out to us on GoReleaser discord channel. We would love to hear from you!

Version strategy and release cadence: the future

Wed, 27 Sep 2023 00:00:00 +0000

A couple of weeks ago, I got a couple of complaints about the way GoReleaser is being versioned - more precisely, the fact that deprecated options are removed in minor instead of major versions.

Those complaints are valid, and today I’m announcing how I plan to move forward.

History

Before we do that, I feel like I should explain how we got in this position first.

GoReleaser was in a 0ver¹ scheme for almost 5 years. We had a whopping 468 v0.x.x releases. Let me repeat: four hundred and sixty eight v zeroes.

In fact, v1 was launched less than 2 years ago, in November, 2022.

Like many other things, the way we handle deprecations was from that time. A time in which GoReleaser never had major releases, because there wasn’t one: we would add the deprecation notice to the deprecations page and warn about it in the release’s output if you use any of them, and, after roughly 6 months, remove the deprecated option and move on with life.

Breaking changes are allowed in v0, so, there were no broken promises.

On the other hand, v1 is a major version, so it should not introduce breaking changes.

In retrospect, my mistake was never stopping to think about it again after v1.

Going forward

Thankfully, I was nudged in the right direction, so, from now on, we’ll do things properly.

The plan is as follows:

We’ll have 1 minor release 1-2 months (when we have some material);
Bug fixes will still be released as patch releases in the latest minor;
Deprecations will continue to be added in minor releases (but not removed);
When we have a good amount of deprecations, we’ll launch a new major, removing them completely. I think this will probably happen about once a year.

So, if you lock your CI to get v1.x.x, you might get new deprecation warnings, but no breaking changes.

You can then better plan when to upgrade your apps to the latest major, without having to lock to a specific minor/patch release.

Supporting old versions

I understand GoReleaser has become the de-facto tool to release Go projects. I don’t know how many users we have (because we don’t track you), but judging by some code searches on GitHub, there are thousands of repositories using it.

GoReleaser is also a big project. Maintaining it could already be a full-time job, but, it isn’t. I work on it on my free time, which is limited - just like yours.

All that being said, I understand that big companies and teams rely on GoReleaser, and some don’t release as often.

With that in mind, GoReleaser Pro customers will have more time to update: I’ll keep launching patch releases of the latest major containing relevant bug fixes and security-related fixes.

If you use the OSS version, you can either pin to the previous major, or update to the new one. You can also get a GoReleaser Pro license, and help fund this project.

I haven’t yet developed the exact rules for which bug fixes will get backported or not, but I’m quite confident that it’ll be a mix of “fixes for really bad bugs” and “a customer is experiencing it and asked it to be fixed”, and, of course, any security-related fixes.

So, when v2?

Probably in a couple of months.

Stay tuned! 📰

Early access

Since a couple of weeks ago, we’re building a new nightly automatically every week.

You can already use nightly as the version in our GitHub Action if you can’t wait for a new feature that’s already on main.

This works for both the Pro and OSS distributions.

Summing up

The TLDR:

new major version ~yearly;
new minor version every ~two months;
new patch versions whenever its needed, in the latest minor only;
Pro latest version keep getting security updates and relevant bug fixes;
nigtlies weekly for both Pro and OSS;

Thank you notes

I would like to publicly thank everyone who commented and shared both their pains and their experiences in the discussion that started all this, and specially, @LandonTClipp, who created it.

All of us that do OpenSource know how easy a conversation like this could have gone south. Thankfully, this was not the case here. 💌

Thank you, for real. Thank you for patience, for the contributions, and for pointing out ways I can make GoReleaser better.

See you all soon!

yes, I know this is kind of a joke. ↩︎

Announcing GoReleaser v1.21 - mostly bug fixes

Fri, 22 Sep 2023 00:00:00 +0000

A boring release, mostly bug fixes. Boring is good.

Highlights

You can now sort tags by semver in GoReleaser Pro
Docker pushes will now be retried when the registry yields a 503. It’ll retry 10 times.
Winget: added support for package_dependencies and update schema version to 1.5.0.
GoReleaser will now run against Gerrit, Soft-Serve, and other Git providers, as long as the SCM release is disabled.
You can now ignore Git tags that match a regular expression.
You can now skip pre build hooks on goreleaser build.
Properly go mod handling on pre-mods Go versions.
WASI support.
New templateable fields and functions.
Several bug fixes, specially when the runtime OS is Windows.

Besides that, some important refactories that should help evolving GoReleaser further:

--skip merges all the --skip-* flags, and will be extended to more features (open an issue requesting what you need 📩).
Template error handling was improved.
We also updated GoReleaser to Go 1.21.

And, as always, several bug fixes and documentation updates!

Windows

GoReleaser was never properly/extensive tested on Windows. It somewhat works, but there are many rough edges, and potentially some bugs here and there.

To make Windows a first-class runtime for GoReleaser, I started trying to make CI pass on Windows. It’s a bit hard to evolve it as I don’t really use Windows, and end up having to juggle around VMs and/or CI.

If you use Windows regularly and want to contribute to OSS, ping me on our Discord, I’m happy to help you in any way you need, especially if you are a beginner in the field and/or Go.

Blog

Our blog was migrated to a new address (and out of medium)!

You can read the announcement here.

It still a work in progress, though. You can also see the still-open issue here

The old address will still be up indefinitely, but we won’t be updating it any longer.

Other news

GoReleaser now has ~12.1k stars and 352 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by contributing features and bug fixes, or by donating. You may also be interested in buying a GoReleaser Pro license.

You can find out more here.

Welcome to our new blog

Thu, 14 Sep 2023 00:00:00 +0000

We are in the process of migrating our blog from Medium to here.

Medium is proprietary, and I don’t particularly like it very much.

Now that material-mkdocs has a blog feature, I started migrating the blog to here.

You can follow the progress in this issue.

You can also subscribe to the RSS feed!

Thanks, I hope you enjoy the new home. 😄

Note

Guest Posts

We are also very happy to accept guest posts!

If you feel like it, you can open a pull request adding your post to ./www/docs/blog/posts/, and/or join our Discord and discuss in the blog channel.

Announcing GoReleaser v1.20 — a quality-of-life release

Wed, 09 Aug 2023 00:00:00 +0000

A little over 100 commits in small-ish quality-of-life improvements.

This is not a flashy release, but I bet you’re going to like it anyway 😄

Highlights

Nightlies

I’ve been releasing GoReleaser Pro Nightlies for a while now, but it never had a fixed schedule, and the OSS version never had a nightly release either.

Starting now, the Pro Nightly will be released every Wednesday, and the OSS every Thursday.

GoReleaser Pro improvements

GoReleaser Pro added a few new features:

ability to automatically check boxes in PR templates
alternative names for Homebrew formulas
Dockerfile templated contents
HTTP & Artifactory upload matrix
nFPM templated_scripts
goreleaser release --single-target
Release’s footer/header can be set to file paths/URLs in the configuration file

Nix

We added Nix support in the previous release, and in this one we added a few improvements:

zip support
the ability to define runtime dependencies
make it easier to extend with a new extra_install option

`extra_install`

Speaking of extra install instructions, we added this option to brew too.

`mod_timestamp`

We added the ability to set a mod_timestamp to both metadata files and to universal binaries.

Other improvements and bug fixes

This release also adds a few other small improvements, here’s a few of them:

Scoops now support arm64
Winget got the PortableCommandAlias option
Release on GitHub now has the make_latest option
You can now disable custom publishers using templates
goreleaser init and overall goreleaser release output improvements

Make sure to read the full release notes, and the pro version release notes as well.

As always, we also had a bunch of bug fixes and documentation improvements.

Other news

GoReleaser now has ~11.9k stars and 348 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by contributing features and bug fixes, or by donating. You may also be interested in buying a GoReleaser Pro license.

You can find out more here.

Announcing GoReleaser v1.19 — the big release

Wed, 28 Jun 2023 00:00:00 +0000

Almost 200 commits adding Nix, Winget, and much more…

This release took almost 2 months (!), and I hope the wait was worth it!

Without further ado, let’s dive in!

Highlights

Security improvements

We got a CVE on nFPM and another one on GoReleaser.

It is unlikely that you were affected by this, but it’s worth taking a look just in case.

Both incidents were fixed in this release.

Open pull requests for Homebrew, Krew, Scoop

You can now instead of just pushing to a branch, push and open a pull request. It even works cross-repository!

Here’s an example:

.goreleaser.yaml

brews: # can be brews, krew, scoops, etc...
 - # ...
 repository:
 owner: john
 name: repo
 branch: "{{.ProjectName}}-{{.Version}}"
 pull_request:
 enabled: true
 base:
 owner: mike
 name: repo
 branch: main

GoReleaser will also read the .github/PULL_REQUEST_TEMPLATE.md and prepend it to the PR description if it exists!

Nix

We added support to generate Nixpkgs. We don’t generate Nixpkgs that compile from source, though.

Instead, we use the already built archives.

This decision was made because this way we can support closed-source software as well as Open Source. The idea here is that you create your own NUR and instruct your users to install from there.

Example:

.goreleaser.yaml

nix:
 - name: goreleaser-pro
 repository:
 owner: goreleaser
 name: nur
 homepage: https://goreleaser.com
 description: Deliver Go binaries as fast and easily as possible
 license: unfree
 install: |-
 mkdir -p $out/bin
 cp -vr ./goreleaser $out/bin/goreleaser
 installManPage ./manpages/goreleaser.1.gz
 installShellCompletion ./completions/*

Winget

Now that Winget supports installing zip packages, GoReleaser added support to generate the needed manifests, and you can then PR them to microsoft/winget-pkgs.

Example:

.goreleaser.yaml

winget:
 - name: goreleaser-pro
 publisher: goreleaser
 license: Copyright Becker Software LTDA
 copyright: Becker Software LTDA
 homepage: https://goreleaser.com
 short_description: Deliver Go binaries as fast and easily as possible
 repository:
 owner: goreleaser
 name: winget-pkgs
 branch: "goreleaser-pro-{{.Version}}"
 pull_request:
 enabled: true
 draft: true
 base:
 owner: microsoft
 name: winget-pkgs
 branch: master

PS: when you open a PR to microsoft/winget-pkgs, you are expected to fill the PR template there… Don’t forget to do it! 😄

Ko improvements

The Ko pipe will now ignore empty tags (e.g. if a template evaluate to an empty string).

Ko also now properly registers its manifests within GoReleaser’s context, so you can sign them with docker_signs.

Deprecations that were permanently removed

Some things that were deprecated for over 6 months were removed in this release:

archives.replacements
archives.rlcp

There are also other deprecations to be removed soon!

Check the deprecations page to find out more, and run goreleaser check every now and then to see if your configuration file is good!

Templates

More fields now accept templates:

dockers.skip_push
docker_manifests.skip_push
scoops.description
scoops.homepage
snapcrafts.title
snapcrafts.icon
snapcrafts.assumes
snapcrafts.hooks

On the same token, there are a couple of new template functions and fields:

{{.IsNightly}} (always false on OSS)
{{.Checksums}} can be used in the release body template
{{envOrDefault "FOO" "bar" }} returns the value of $FOO if it is set, otherwise returns bar

Standard repository

Historically, you would set brews.tap, krews.index and etc. Internally, they all used the same structure: a repository. “A repository” is also (probably) how most think about these fields.

To make things easier on everyone, now all those fields are named repository instead.

You can check the deprecations page to find more information.

Continue on error

From this version onward, GoReleaser will not hard-stop when Homebrew, Nix, and other pipes fail to publish.

Our understanding is that having a broken, stopped-in-the-middle release, is worse than continuing and reporting all the errors in the end, so you can fix them all in a single pass and do a point-release.

You can still get the previous behavior by passing the --fail-fast flag.

Upx

As promised, upx now has more filters: goos, goarch, goarm and goamd64.

The Telegram announcer now supports choosing the message format.

You can also use mdv2escape to escape sequences accordingly to mdv2.

Changelog

Besides just excluding commits that match some regular expressions, you can now include only the commits that match one of them.

Example:

.goreleaser.yaml

changelog:
 filters:
 include:
 - "^feat.*"
 - "^fix.*"

Bugfixes et al

We also had a bunch of bugfixes and documentation improvements, as always.

Other news

GoReleaser now has ~11.8k stars and 340 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Helping out

You can help by contributing features and bug fixes, or by donating. You may also be interested in buying a GoReleaser Pro license.

You can find out more here.

Announcing GoReleaser v1.18 — the maintainers month release

Fri, 05 May 2023 00:00:00 +0000

May is the maintainers month, so I would first like to thank all the maintainers out there for the hard work, you rock!

Now, onto new features!

Highlights

Native `upx` support

This version introduces a upx root configuration section, which allows you to compress the binaries.

Go built binaries are known for being, well, not small. There are a couple of strategies to remediate it, for example, passing -s -w as -ldflags to go build - which GoReleaser does by default since the beginning.

I hope that, by making it easier to make the binaries even smaller, we get more projects to do that, better supporting environments with bad download speeds and/or low storage.

For reference, running upx through GoReleaser binaries shrunk them from ~51M to ~15M - about 27% of its original size.

In a future release we’ll also add more filters to the upx configuration.

Documentation.

PS: if you use this on GitHub Actions, I recommend using crazy-max/ghaction-upx to install the latest and greatest upx version!

Report binaries sizes

Also related to binary sizes, you can now enable size reporting. After the build phase, GoReleaser will display the sizes and paths of all built artifacts.

These sizes will also be available in dist/artifacts.json, so you might parse and export them somewhere else.

Documentation.

Template improvements

This is a recurrent subject in most releases, I know: more templateable fields! This release is not different in that regard:

New {{ .IsGitDirty }} template variable
nfpms.*.package_name now allows templates

Scoops

To be in better parity with brews and others, scoop is deprecated in favor of scoops, and you can now define multiple Scoop manifests in the same .goreleaser.yaml file.

Documentation.

Publish Homebrew taps, Scoop manifests and Krew plugins to plain Git repositories

Historically, you could only publish to GitHub, GitLab and Gitea, which used their respective APIs.

Now, you can push to any Git repository. This can be specially useful for people self-hosting Git servers, like Soft Serve for example.

Documentation:

Deprecation warnings rolled out

On GoReleaser Pro, the initial way to access custom environment variables was {{.var_name}}. That could conflict with GoReleaser’s internal state, and was deprecated in favor of {{.Var.var_name}}.

Now, the old way is officially removed for good.

Output improvements

I always aim for the GoReleaser output to be concise yet complete-ish.

This release contains a few improvements in that regard, like the removal of sorting the log keys alphabetically, so they are displayed in the intended order.

Another change is in printing the artifacts’ path: it will now, when possible, use relative paths in order to make the output a bit better.

Last but not least, we have a new goreleaser --version output using go-version.

It’s not much, but it’s honest work!

Check multiple configuration files

GoReleaser Pro allows you to include configuration files, which might lead to repositories of reusable .goreleaser.yaml files parts.

One of the advantages of this is being able to, for example, change some configuration in a single place and that is then applied to all the projects that use that file.

The problem is that goreleaser check only ever allowed to check one file at a time.

On v1.18 we added the ability to, instead, pass as many configuration files you need as arguments. This also allows you to use shell globs, e.g.:

goreleaser check goreleaser*.yaml

You can then add this to your CI, so your GoReleaser configuration files are always validated and hopefully free of deprecation notices. 🤝

No AUR for v1.18.0

I’m not sure if AUR is under maintenance or if there something else going on, but I’m unable to clone my AUR packages using their private URLs.

I didn’t want to hold the release because of it, so I’ll be releasing a patch as soon as the problem is fixed, whatever the problem is.

Thanks for the comprehension. 😃

Other news

We have a whole lot of example repositories, including Zig, GoReleaser-Cross, GoReleaser Pro features, and more. Check it out!
GoReleaser now has ~11.6k stars and 336 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Download

You can install or upgrade using your favorite package manager, or see the full release notes and download the pre-compiled binaries here and here (for Pro).

Announcing GoReleaser v1.17 — the late Easter release

Mon, 10 Apr 2023 00:00:00 +0000

The Easter release is here!

It is packed with some juicy features and tons of bug fixes and quality-of-life improvements.

Let’s take a look:

Highlights

GoReleaser Pro now has a templated_files (or templated_extra_files) in several fields: archives, blobs, checksum, custom_publishers, docker, nfpms, release, snapcrafts and source
GoReleaser can now open pull requests of homebrew taps, brews and scoop instead of just pushing it to a branch
Some smaller improvements in templates, like the new .Now and .IsDraft template variables (tip: {{ .Now.Format "2006" }} to format the date time as you want)
Default Parallelism now matches Linux container CPU
Some errors have been improved to be more clear on how to fix them
Many improvements in the documentation
As always, a lot of bug fixes, dependency updates and improvements!

You can install the same way you always do, and you can see the full release notes here and here (for Pro).

Other news

We have a whole lot of example repositories, including Zig, GoReleaser-Cross, GoReleaser Pro features, and more. Check it out!
GoReleaser now has ~11.4k stars and 333 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Announcing GoReleaser v1.16 — the late February release

Mon, 06 Mar 2023 00:00:00 +0000

The February release got a little late… better later than even later, I guess! 😄

It is packed with some juicy features and tons of bug fixes and quality-of-life improvements.

Let’s take a look:

Highlights

On GoReleaser Pro you can now add dividers between groups in the changelog. Documentation.
GoReleaser Pro also gets a new template variable: {{ .Artifacts }}, which you can iterate over to build, for instance, custom scripts. Oh, how can you build custom scripts? I’m glad you asked! Documentation.
Concluding our Pro-exclusive feature-set for this release: template files! You can template entire files, and they’ll get added to the release! Documentation.
All GoReleaser distributions get a new subcommand: healthcheck.
The single build statement has been undocumented for many years, and has been deprecated.
You can now announce to OpenCollective. Documentation.
Templating updates: nfpms get {{ .ConventionalExtension }}, new templateable fields, base (as in filepath.Base) template function, and more.
When running on a new project, with no project_name set, and no git remotes, GoReleaser will now try to infer the project name from the go.mod file instead of erroring.
GoReleaser is now built with Go 1.20.
As always, a lot of bug fixes, dependency updates and improvements!

You can install the same way you always do, and you can see the full release notes here and here (for Pro).

Other news

We have a whole lot of example repositories, including Zig, GoReleaser-Cross, GoReleaser Pro features, and more. Check it out!
GoReleaser now has ~11.3k stars and 327 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Announcing GoReleaser v1.15 — the first of 2023

Mon, 30 Jan 2023 00:00:00 +0000

Keeping our pace of 1 minor a month, this is the January 2023 release.

It is packed with some juicy features and tons of bug fixes and quality-of-life improvements.

Let’s take a look:

Highlights

GoReleaser Pro now can now create changelog subgroups
You can create and push Docker images/manifests with Ko (big thanks to @developerguyba and @ImJasonH for all the work here)
More templateable fields: nfpms.apk.signature.key_name, release.disable, release.skip_upload, snaps.grade, telegram.chat_id
Deprecated --clean in favor of --clean
As always, a lot of bug fixes and documentation improvements

You can install the same way you always do, and you can see the full release notes here and here (for Pro).

GitHub Action incident

Last Friday (Jan 27th), we had a rather big incident due to a GitHub website change. We were using a URL to get the release that was not in the API domain, but was working well for a couple of years. GitHub changed it, and we, as well as many other projects, got an incident in our hands. This is definitely our fault, though, we should have been using the guaranteed API endpoints instead. That said, we fixed it rather quickly, even though it was a Friday night. Since then, we also made more changes to use the releases.json served by our website instead of GitHub’s API, which also avoids rate limits and issues with GHE users. I also wanna give huge props to @crazy-max for working hard on all that, as well as everyone who helped debug and test everything on #389.

Other news

GoReleaser now has ~11.2k stars and 322 contributors! Thanks, everyone!
We are now present in the fediverse, give us a follow at @goreleaser@fosstodon.org.
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Fast and Furious Building OCI compatible Container Images with GoReleaser and ko

Mon, 30 Jan 2023 00:00:00 +0000

GoReleaser and ko are popular open-source, well-recognized projects, especially in the containerization and open-source ecosystem for Go applications. Many people use these projects for their Go applications because they are pretty straightforward and CI-friendly tools that make your releasing artifacts (binary and container image) process super elegant, which also helps you focus more on developing the business logic rather than planning to release software type of works.

I’m so glad to announce that we finally integrated these fantastic projects!

If you are interested in learning more about the development process of that feature, here is the PR you can take a look.

As a result, starting from GoReleaser v1.15, you can build container images by setting configuration options for ko in GoReleaser without having ko installed on your environment.

This post will be a quick walkthrough to guide people about how things work.

Before diving into that, let’s refresh our minds about these projects with a quick recap.

GoReleaser is a tool for creating and releasing Go projects. It automates the process of building, packaging, and publishing Go binaries and container images, basically the fanciest way of releasing Go projects. It is a super user-friendly, easy-to-use, go-to CLI tool and also provides GitHub Actions to be CI-friendly. It also includes a bunch of features for mitigating the risks of the software supply chain attacks, such as generating SBOMs, signing the artifacts, and many others. To get more detail, here is the blog post for you.

On the other hand, ko is specifically designed for building and publishing container images for Go projects. But the utmost vital features in ko are that it doesn’t require you to run any Docker daemon or write well-designed Dockerfiles to make the build process cache-efficient, fast and secure. The good news is that ko will consider all these and build OCI-compatible container images with all the security options enabled by default, such as using build arguments while making Go binaries for reproducibility, generating SBOMs, and uploading them to the OCI registry, using the smallest and CVE-less base image from Chainguard images and providing base information using OCI base image annotations and also it makes easier multi-platform builds by using the cross-compilation in Go. To get more detail, here is the blog post for you.

It is worth mentioning that ko applied to become a CNCF sandbox project the last year, and glad to see that this application got accepted by the CNCF, which means that ko is now officially a CNCF Sandbox project.

Without further ado, let’s dive into the details of the integration by showing it in a real-world example.

You will find all the source code in GitHub repository, here.

Let’s start with creating a proper directory to host the source code:

$ mkdir -p goreleaser-with-ko
$ cd goreleaser-with-ko

Next, initialize the project:

go mod init github.com/<username>/goreleaser-with-ko
cat <<EOF > main.go
package main

import (
 "fmt"
 "os"
)
var (
 // Version is the current version of the application.
 Version = "main"
)
func main() {
 fmt.Fprintf(os.Stdout, "GoReleaser supports ko! Version: %s", Version)
}
EOF

It is time to create the configuration file for GoReleaser, which is .goreleaser.yml.

The easiest way of creating that file is run: goreleaser init, which requires GoReleaser CLI to be installed on your environment; please refer to the installation page here to install it.

# it will create the .goreleaser.yml configuration file
# with bunch of default configuration options.
$ goreleaser init
• Generating .goreleaser.yaml file
• config created; please edit accordingly to your needs file=.goreleaser.yaml

Next, set ko configuration options into .goreleaser.yml. Fortunately, we have good documentation explaining how we can do this here.

$ cat <<EOF >> .goreleaser.yml
kos:
 - id: goreleaser-with-ko
 platforms:
 - linux/amd64
 - linux/arm64
 tags:
 - latest
 - '{{.Tag}}'
 bare: true
 flags:
 - -trimpath
 ldflags:
 - -s -w
 - -extldflags "-static"
 - -X main.Version={{.Tag}}
EOF

Finally, we’ll automate this workflow on the GitHub Actions platform. To do this, we need to create a proper folder structure, .github/workflows and put the workflow file into it:

$ mkdir -p .github/workflows
$ cat <<EOF > .github/workflows/release.yaml
name: Releasing artifacts with GoReleaser and ko
on:
 push:
 tags:
 - 'v*'
permissions:
 contents: write # needed to write releases
 packages: write # needed for ghcr access
jobs:
 release:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 with:
 fetch-depth: 0 # this is important, otherwise it won't checkout the full tree (i.e. no previous tags)
 - uses: actions/setup-go@v3
 with:
 go-version: 1.19
 cache: true
 - uses: goreleaser/goreleaser-action@v4 # run goreleaser
 with:
 version: latest
 args: release --rm-dist
 env:
 KO_DOCKER_REPO: ghcr.io/${{ github.repository_owner }}/goreleaser-with-ko
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
EOF

As you saw from the file above, we didn’t do anything special about ko installation, but in case you need to install it into your workflow, you can use the setup-ko GitHub Action for that. But how?

Since ko’s core packages that provide such building and publishing capabilities are exported functions, you can use them in your own Go projects to get more detail here. The following projects are great examples of that:

And that’s it. All you need to do at that point is give a tag to your project and wait for the GitHub workflow to be completed to release your software.

$ git commit -m"initial commit" -s
$ git tag v0.1.0 -m"first release"
$ git push origin v0.1.0

One last note: please remember to use this feature and provide feedback to help us improve this process. Thanks for reading; I hope you enjoyed it; see you in the next blog posts.

Releasing multi-platform container images with GoReleaser in Azure DevOps

Tue, 10 Jan 2023 00:00:00 +0000

Introduction

In this article, we learn how to use GoReleaser to build and release a multi-platform container image to Azure Container Registry in Azure DevOps.

This is particularly interesting for teams, who are using mainly Azure and Azure DevOps for their projects and want to build and release container images to Azure Container Registry.

I try to follow the great article on how to create multi-platform container images using GitHub actions written by Carlos, the core maintainer of GoReleaser. If you had no chance to read his blog, here is the link to it.

Before we start, let’s take a look on the prerequisites.

Prerequisites

Azure DevOps account.
The GoReleaser Azure DevOps Extension installed.
Azure account.
GoReleaser installed on your local machine.

The sample application

Before we can start to set up our pipeline and infrastructure components, lets have a look at the sample application we are going to use in this demo. To keep things simple, I created basic Hello World server using mux library from the Gorilla Web Toolkit.

Add the library to the go.mod file:

module dev.azure.com/goreleaser-container-example
go 1.19
require github.com/gorilla/mux v1.8.0

After adding the library, we can move over to implement the basic logic of the application. The server should return a Hello World! string, when we curl the root path of the server.

In mux this is done, with adding a new route to the router and adding a handler function to it. In my case called HelloWorldHandler.

Then we can start the server and listen on port 8080.

package main

import (
 "log"
 "net/http"
 "os"
 "strings"

 "github.com/gorilla/mux"
)

const (
 // Port is the port the server will listen on
 Port = "8080"
)

func HelloWorldHandler(w http.ResponseWriter, r *http.Request) {
 w.Write([]byte("Hello World!"))
}

func main() {
 r := mux.NewRouter()
 r.HandleFunc("/", HelloWorldHandler)
 port := os.Getenv("PORT")
 if port == "" {
 port = Port
 }
 for _, env := range os.Environ() {
 if strings.HasPrefix(env, "TEST") {
 log.Printf("%s", env)
 }
 }
 log.Println("Listening on port " + port)
 log.Fatal(http.ListenAndServe(":"+port, r))
}

As we want to create a container image, we need to add a Dockerfile. GoReleaser will then build our container image by copying the previously built binary into the container image. Remember: We don’t want to rebuild the binary. So no multi-stage Dockerfile. This way we are sure, that the same binary is used for all distribution methods GoReleaser is offering, and we intended to use.

# Dockerfile
FROM cgr.dev/chainguard/static@sha256:bddbb08d380457157e9b12b8d0985c45ac1072a1f901783a4b7c852e494967d8
COPY goreleaser-container-example \
 /usr/bin/goreleaser-container-example
ENTRYPOINT ["/usr/bin/goreleaser-container-example"]

You may spot that I use a static container image as base image from Chainguard. Chainguard images are designed for minimalism and security in mind. Many of the images provided by Chainguard are distroless, which means they do not contain a package manager or any other programs that are not required for the specific purpose of the image. Chainguard images are also scanned for vulnerabilities and are regularly updated. You can find more information about Chainguard images here: Chainguard Images *Chainguard Images are security-first container base images that are secure by default, signed by Sigstore, and include…*www.chainguard.dev

Let’s pause a minute here and test that everything is working as expected. We can test the application by running it locally:

GOOS=linux GOARCH=amd64 go build -o goreleaser-container-example .
docker buildx build --platform linux/amd64 -t goreleaser-container-example .
docker run -p 8080:8080 goreleaser-container-example

After spinning up the container, you should see the following output:

2023/01/10 10:49:31 Listening on port 8080

And if we run a curl command in another terminal, we should see the following output:

curl localhost:8080
Hello World!

Perfect! Everything works as we expected it. Now we can start working on the GoReleaser parts.

GoReleaser config file

We need to provide a goreleaser.yaml config file in the root of our project to tell GoReleaser what to do during the release process. In our case to let GoReleaser to build our container image. To create the goreleaser.yaml we can run following command:

goreleaser init

This should generate the config file for us:

 • Generating .goreleaser.yaml file
 • config created; please edit accordingly to your needs file=.goreleaser.yaml

The good part when using the init command is, that the goreleaser.yaml comes with some default values. We need to change content as we not need everything GoReleaser is doing by default. Here is the content of the goreleaser.yaml for this demo:

# This is an example .goreleaser.yml file with some sensible defaults.
# Make sure to check the documentation at https://goreleaser.com
before:
 hooks:
 # You may remove this if you don't use go modules.
 - go mod tidy
builds:
 - env:
 - CGO_ENABLED=0
 goos:
 - linux
 - darwin

Later we add the part needed to create the multi-platform container images but for now we dry-run the release process with following GoReleaser command:

goreleaser release --snapshot --rm-dist

Next to the logs of GoReleaser release process, you should also have a dist folder with all the binaries in it.

Exclude this folder in your .gitignore file, to prevent accidentally committing the binaries to your repository.

Azure Container Registry

If you already have an Azure Container Registry you can skip the parts of the creation of the Azure Container Registry.

There are several ways, you can create a container registry: You can use the Azure Portal, the Azure CLI, the Azure PowerShell or your favorite Infrastructure as Code tool of choice.

In this demo, I will use the Azure CLI to create the container registry. You can find more information about the Azure CLI here.

First log into the Azure account with the Azure CLI:

az login

We then need to create the resource group and then the container registry service with following commands:

# create a resource group in WestEurope datacenter
az group create --name goreleaser-rg --location westeurope
# create the Azure Container registry
az acr create --resource-group goreleaser-rg --name mygoreleaserregistry --sku Basic

When the container registry is up and running, we can add the dockers configuration to our goreleaser.yaml. But we need to name of our container registry beforehand.

Use following command to retrieve the name:

az acr show --resource-group goreleaser-rg --name mygoreleaserregistry --query loginServer --output tsv

This is the new part we need to add to our goreleaser.yaml, to activate the build of the container image and manifest.

If you want to know more about the manifest files, I wrote an article about it here.

---
dockers:
 - image_templates:
 [
 "mygoreleaserregistry.azurecr.io/{{ .ProjectName }}:{{ .Version }}-amd64",
 ]
 goarch: amd64
 dockerfile: Dockerfile
 use: buildx
 build_flag_templates:
 - --platform=linux/amd64
 - image_templates:
 [
 "mygoreleaserregistry.azurecr.io/{{ .ProjectName }}:{{ .Version }}-arm64",
 ]
 goarch: arm64
 dockerfile: Dockerfile
 use: buildx
 build_flag_templates:
 - --platform=linux/arm64/v8
docker_manifests:
 - name_template: "mygoreleaserregistry.azurecr.io/{{ .ProjectName }}:{{ .Version }}"
 image_templates:
 - "mygoreleaserregistry.azurecr.io/{{ .ProjectName }}:{{ .Version }}-amd64"
 - "mygoreleaserregistry.azurecr.io/{{ .ProjectName }}:{{ .Version }}-arm64"
 - name_template: "mygoreleaserregistry.azurecr.io/{{ .ProjectName }}:latest"
 image_templates:
 - "mygoreleaserregistry.azurecr.io/{{ .ProjectName }}:{{ .Version }}-amd64"
 - "mygoreleaserregistry.azurecr.io/{{ .ProjectName }}:{{ .Version }}-arm64"

Azure DevOps

With the infrastructure done and GoReleaser config finished, we can set up Azure DevOps Service.

Switch to the Service Connections screen

Click on the New service connection button

Select Azure Container Registry and connect your Azure subscription to it

Time for the last part of our demo: Setting up the Azure DevOps pipeline. I will not go too much into detail about the pipeline, as this is not the focus of this demo. But I will show you the important parts of the pipeline.

First notable part is the multi-platform command task. I simply followed the instructions from this article on how to setup the task to build multiarch images.

Next section in the pipeline is the GoReleaser task. This task is using the GoReleaser extension from the Azure DevOps Marketplace. You can find more information about the extension here.

I just added the args field and set the value to release --rm-dist and defined a condition to only run the task on a tag as GoReleaser will not release on a “dirty” git state.

This is the complete pipeline:

trigger:
 branches:
 include:
 - main
 - refs/tags/*
variables:
 GO_VERSION: "1.19.4"
 DOCKER_BUILDKIT: 1
pool:
 vmImage: ubuntu-latest
jobs:
 - job: Release
 steps:
 - task: GoTool@0
 inputs:
 version: "$(GO_VERSION)"
 displayName: Install Go
 - task: Docker@2
 inputs:
 containerRegistry: "goreleaser"
 command: "login"
 addPipelineData: false
 addBaseImageData: false
 - task: CmdLine@2
 displayName: "Install multiarch/qemu-user-static"
 inputs:
 script: |
 docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
 - task: goreleaser@0
 condition: and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/tags/'))
 inputs:
 version: "latest"
 distribution: "goreleaser"
 workdir: "$(Build.SourcesDirectory)"
 args: "release --rm-dist"

To run a release, you need to create a tag in Azure to get the release process started.

Logs produced during the release process

And you should see in the Repository tab of your Azure Container Registry service in the Azure Portal UI the multi-platform container images.

List of all produced multi-platform container images

Conclusion

In this demo, I showed you how to create a multi-platform container image using GoReleaser and Azure DevOps and store this image in Azure Container Registry for further usage in your Container based Azure services.

Setting up all the parts was pretty straight forward where GoReleaser is doing the heavy lifting for us.

Go ahead and give it a try and let me know what you think about it.

Announcing GoReleaser v1.14 — the Christmas release

Tue, 27 Dec 2022 00:00:00 +0000

Another month, another release! In fact, the last release of the year.

This one in particular marks the 6 years anniversary of GoReleaser, and is packed with new features and improvements.

Let’s see what’s new:

Highlights

GoReleaser Pro can now skip the build of specific Docker images based on a template evaluation result;
GoReleaser Pro build hooks now also inherit the build environment variables
You can now use templates in brews.install, builds.env and archives.files.info
Windows is added as a default OS for builds (amd64 and 386)
New archives.rlcp option: It’ll be the default soon, run goreleaser check to verify your configuration
Allow to customize the tag sorting directive
Deprecate archives.replacements
Allow to set the file info of binaries inside archives
Added a new title template function
As always, a lot of bug fixes and documentation improvements

You can install the same way you always do, and you can see the full release notes here and here (for Pro).

Other news

GoReleaser now has ~11k stars and 316 contributors! Thanks, everyone!
We are now present in the fediverse, give us a follow at @goreleaser@fosstodon.org.
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Announcing GoReleaser v1.13 — the November release

Fri, 18 Nov 2022 00:00:00 +0000

Another month, another release!

Like the previous 2 releases, this is a beefy one: over 100 commits from 15 contributors!

This one also marks the point of 1 year since v1.0.0!

Highlights

docker, docker buildx and podman (on GoReleaser Pro) will now use the image digest when creating docker manifests. This should help ensure that what you are releasing wasn’t changed by an outside tool.
- In the same token, the Docker images and manifests signing with cosign will now use the digest by default.
GoReleaser can now announce to Mastodon!
Ability to create Arch Linux packages, btw.
- Still regarding nFPM, dsts with trailing slashes will now have the same behavior as tools such as cp with trailing slashes.
For Windows fans: you can now create and publish nupkgs (Chocolatey packages)!
Better support for building and publishing shared or static libraries.
Many bug fixes and documentation improvements.

You can install the same way you always do, and you can see the full release notes here and here (for Pro).

Other news

GoReleaser now has ~10.9k stars and 313 contributors! Thanks, everyone!
We are now present in the fediverse, give us a follow at @goreleaser@fosstodon.org.
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.
We made a bunch of progress towards getting 100% in the OpenF Best Practices assessment… and we’re almost there.

Announcing GoReleaser v1.12 — the more-than-a-hundred commits release

Mon, 17 Oct 2022 00:00:00 +0000

The previous release had ~100 commits, and this one has 149 since previous feature release!

Definitely a big release, with some big features. Let’s dive in!

Highlights

GoReleaser Pro can now split and merge releases;
GoReleaser Pro can now filter paths for changelogs;
GoReleaser Pro has now a continue command, which merges publish and announce;
GoReleaser Pro can now filter targets by GGOOS and GGOARCH as well;
AUR can now set the backup options;
GoReleaser completions are now published to Fig as well;
Blobs have more templateable fields;
The Telegram announcer now supports markdown;
NFPMs can now create iOS packages (for jailbroken iPhones only);
Buildpacks were permanently removed;
As always, a lot of bug fixes, documentation improvements and dependencies updates;

You can install the same way you always do, and you can see the full release notes here and here (for Pro).

Other news

GoReleaser now has ~10.8k stars and 305 contributors! Thanks, everyone!
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.

Announcing GoReleaser v1.11 — the hundred commits release

Sun, 28 Aug 2022 00:00:00 +0000

This release took a while, for all the good reasons: a ton of new features and bug fixes for your delight!

Oh, and, over 100 commits!

It might be the biggest GoReleaser release in commits made, although I have no data to back it up — except my memory.

Highlights

GoReleaser Pro can now skip Fury publishing with --skip-fury;
GoReleaser Pro now has before and after hooks for archives;
GoReleaser is now compiled using Go 1.19, and supports new Go 1.19 targets (GOARCH=loong64);
New .ArtifactExt template field and new split function;
You can now add more files/folders/globs to source archives (e.g. the vendor folder);
The JSONSchema is finally (properly) fixed;
Skip uploading artifacts into the release, without skipping the whole release;
Changelogs using the github strategy now use the short commit as well;
Allow to keep a single draft GitHub release;
Allow to set target_commitish in GitHub releases;
Allow to set up mTLS in the HTTP uploads pipe;
Option to strip the binary parent folder in the archive;
Couple of improvements in the nFPM: added Termux packaging, changelogs and provides support.
The GoReleaser Docker image now logs in into the GitLab Registry if its environment variables are set;
Homebrew taps can now define their dependencies’ versions;
The deprecated Gofish feature is now fully removed;
As of every release, a healthy amount of bug fixing;
Many documentation improvements.

Other news

GoReleaser now has ~10.5k stars and 292 contributors! Thanks, everyone!
GoReleaser now has a LinkedIn page;
We eventually discuss new features in our Discord server. Join the conversation!
nFPM had new releases as well, check it out.
GoReleaser Pro now has nightly releases;

Announcing GoReleaser v1.10 — the summer release

Mon, 04 Jul 2022 00:00:00 +0000

Fun fact: it is actually winter now here in Brazil. Regardless, this release is packed with new features, quality-of-life improvements and bug fixes!

Highlights

GoReleaser Pro can now skip global after hooks with -skip-after;
GoReleaser Pro can now split the release process into “prepare”, “publish” and “announce”. Check out goreleaser release --help,goreleaser publish --help and goreleaser announce --help for more details;
The entire GoReleaser output is now using caarlos0/log, which is a more-or-less drop-in apex/log replacement. It uses Charm’s technology for its implementation and has a slightly different proposal and feature set;
New -skip-docker and -skip-before flags added;
goreleaser build now allows repeatable -id filters;
The build process now uses 1 parallelism permit for each binary being built, regardless of how many build configurations you have;
GoReleaser can now load a config file from STDIN (using -config -);
Builds can now override env in for a given target;
release.repo.owner and release.repo.name can now be templated;
Changelog grouping is now processed in the order they are declared and rendered in the order of their order field;
GoReleaser now logs the duration of “slow” pipes;
The deprecated nfpms.empty_folders is now removed;
The deprecated handling of Windows ARM64 builds on Go versions older than 1.17 is now removed;
As of every release, a good amount of bug fixing;
And a bunch of documentation improvements.

Other news

GoReleaser now has ~10.3k stars and 285 contributors! Thanks, everyone!
Our Discord server is getting new members almost daily. Join and chat with us!
Check out a preview of the split release phases feature:

Nightly builds with GoReleaser and GitHub Actions

Sun, 22 May 2022 00:00:00 +0000

Our flow for nightly builds

Nightly builds offer other benefits like insight into a project’s activity. They also help to highlight the continuous delivery process. In this blog, I’ll go over how my team and I set up nightly builds using GoReleaser and GitHub. I’ll explain it using a bottom-up approach, so you can better understand what drove our decision and the design of the release procedure.

Before we dive in here’s a quick overview of how the Conduit team actually performs releases. A release consists of:

a GitHub release containing binaries for different platforms and a changelog amongst other artifacts.
a Docker image (pushed to GitHub’s Container Registry)

Requirements

One of Conduit’s primary drivers is being developer-friendly, which also means that we want developers (and Conduit users generally) to be able to try out all the latest features and fixes in any way they want: be it a binary they run directly or a Docker image. We also want to be very precise about what exactly is new in a build.

The above means that nightly builds and regular builds should have the same structure. For example, if our regular release contains a changelog, a binary for Linux and a Docker image, then a nightly release should also contain a changelog, a binary for Linux and a Docker image.

Ideally, any change in the release structure should be automatically reflected in both, the regular builds and the nightly builds. Continuing the previous example: if we decide to start supporting Plan9, we ideally change the configuration in one place, and see the change in regular and nightly builds alike. The release structure is defined through a GoReleaser configuration, so for that reason we would like to use a single GoReleaser configuration for both types of builds.

We have a new contribution almost every (work)day, so we want the nightly builds to be scheduled around them. We may get dependency upgrades on weekends, but we’re fine not having a nightly build only for those. And, of course, we want the older releases to be cleaned up. We keep the builds for at most 7 days, so our full list of requirements is as follows:

Nightly builds are “full releases” (i.e. include everything a “normal” release includes)
The existing GoReleaser configuration is used.
Nightly builds are scheduled on each working day
Nightly builds older than 7 days are removed.

Our Process Before Nightly Releases

We chose GoReleaser to automate building the binaries, create a GitHub release, etc. To build the Docker image we use Docker’s GitHub actions and not GoReleaser, because Conduit comes with a built-in UI. This allows for multi-stage Docker builds, while GoRelease only supports single-stage builds.

The two parts we had prior to nightly builds were:

A GoReleaser config: .goreleaser.yml
A trigger for the release, in a GitHub workflow, workflows/release.yml. The trigger is a tag push.

What we have works well for major, minor and patch releases. What this process clearly doesn’t have is scheduling nightly builds nor a cleanup.

Implementing Nightly Builds

Now we come to the design of the nightly build process: A scheduled GitHub action is pushing a nightly tag:

on:
 schedule:
 # * is a special character in YAML, so you have to quote this string
 # doing builds Tue-Sat, so we have changes from Fri
 # available already on Sat
 - cron: "0 0 * * 2-6"

That will trigger the full release. Then, we use a GitHub action to clean up older GitHub releases, and also a GitHub action to clean up older Docker images. All of that together can be found in workflows/trigger-nightly.yml. Here’s the big picture of everything together:

To create a release, GoReleaser and Docker actions are used.
A release is triggered by a tag push.
“Normal” (major, minor, patch) releases are triggered by manually pushing a tag.
Nightly builds (releases) are triggered by pushing a “nightly tag”
A workflow is responsible for pushing the nightly tag and also for the cleanup.

Don’t forget to clean up

Nightly builds will accumulate over time, but we don’t want to keep all of them. In the end, those are not stable releases and relying on them for a longer period of time is not recommended anyway.

We need to clean up older GitHub releases as well as Docker images. Here’s the relevant code snippet from workflows/trigger-nightly.yml:

- name: "Clean up nightly releases"
 uses: dev-drprasad/delete-older-releases@v0.2.0
 with:
 keep_latest: 5
 delete_tags: true
 delete_tag_pattern: nightly
 env:
 GITHUB_TOKEN: ${{ secrets.NIGHTLY_BUILD_GH_TOKEN }}
- name: "Delete nightly containers older than a week"
 uses: snok/container-retention-policy@v1
 with:
 image-names: conduit
 cut-off: 1 week ago UTC
 account-type: org
 org-name: ConduitIO
 keep-at-least: 5
 token: ${{ secrets.NIGHTLY_BUILD_GH_TOKEN }}
 filter-tags: "*-nightly*"

We’ve been running this for a few weeks now (and also started using in another repository) and it’s been working fine. One of the improvements we’ve identified so far is to announce the nightly release by using GoReleaser.

Announcing GoReleaser v1.9 — the 10k stars release

Wed, 18 May 2022 00:00:00 +0000

This release contains several minor improvements and a couple of new features! Let’s have a look!

Highlights

goreleaser changelog was added to GoReleaser Pro — you can use it to preview your next release changelog
added more build options, enabling you to build test binaries #3064
added go_first_class target options for build #3062
new run script for CIs that don’t have it natively #3075
make it easier to run GoReleaser against a SCM that is not GitHub, GitLab or Gitea #3088
allow to create meta archives #3093
the archive pipe no longer check links are valid, like tar #3103
a lot of bug fixes and docs improvements
we are also experimenting with new ways to share news with our users, the latest is our newsletter

You can see the full changelog here.

Other news

Still no community meeting, sorry 🫠. Link.
We hit 10k stars on our main repository!
GoReleaser now has ~10.1k stars and 277 contributors! Thanks, everyone!
Our Discord server is getting new members almost daily. Join and chat with us!

Announcing GoReleaser v1.8 — the GOAMD64 release

Fri, 15 Apr 2022 00:00:00 +0000

This release’s biggest feature is the GOAMD64 support.

Highlights

support GOAMD64(#3016)
upgraded from yaml.v2 to yaml.v3(#3004)
deprecate gofish (#2999)
added Slack notification options (#2988)
a lot of bug fixes and docs improvements

You can see the full changelog here.

Other news

Still no community meeting, sorry 🫠. Link.
Release Party though! Thanks to everyone who joined!
GoReleaser is now in the ThoughtWorks Technology Radar!
GoReleaser now has ~9.9k stars and 271 contributors! Thanks, everyone!
Our Discord server is getting new members almost daily. Join and chat with us!
nFPM also had a release as well, check it out.

GoReleaser And Software Supply Chain Security

Mon, 28 Mar 2022 00:00:00 +0000

Before talking about the security of the software supply chains, we should mention what should come to our minds first when we are talking about software supply chains. In most basic terms, you can think of software supply chains are anything that’s needed to deliver your product — including all the components you use, for example, your codebase, packages, ** libs, your CI/CD pipeline**, third-party services you use, anything that goes into or affects your code from development to gets deployed into production systems.

https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

The picture above, taken from SLSA (Supply Chain Levels for Software Artifacts), is a security framework, a check-list of standards and controls to prevent tampering, improve the integrity, and secure packages and infrastructure in your projects, businesses, or enterprises, shows us the importance of protecting our workflows that delivers software we built to the customer because there are many places that attackers can attack and gain access to our system.

Unfortunately, the new threats in software development are not only related to the specific company itself. Thanks to CNCF Security Technical Advisory Group, they made a repository to list all the companies’ compromises against supply chain attacks. Trends show that supply chain attacks are increasing at an exponential rate of 4–5x per year, with several thousand last year, the most common being related to dependency confusion or typosquatting, followed by malicious source code injection, so, with the rise of software supply chain attacks, it becomes more critical to secure our software supply chains.

https://www.memesmonkey.com/images/memesmonkey/43/43b3e5ab9f90a6266a163278c025cba5.jpeg

Securing the software supply chain is not an easy task. So many people and organizations have already working on this specific problem, but luckily we have some tools to make that process a bit easier to deal with for us.

Today, we’ll be talking about the GoReleaser project and its features that can help us mitigate the risk of compromises in software supply chains. Then, at the end of this guide, we’ll be demoing everything we talked about to give more practical information about how you can make the supply chain more secure for your Go projects by using GoReleaser.

GoReleaser is a release automation tool for Go projects. The goal is to simplify the build, release, and publish steps while providing variant customization options for all steps. Although GoReleaser is built with CI tools in mind, you only need to download and execute it in your build script. But, of course, you can still install it locally if you want. This is because many projects have already been using GoReleaser for a long time in the open-source world. Also, with the announcement GitHub Actions platform, GoReleaser’s popularity increased, so it takes firm steps towards becoming a defacto standard for releasing Go projects, especially in the GitHub ecosystem.

The first step in securing your supply chain is to create an inventory of the software and libraries being used during your build and deployment cycle.

This is where an SBOM comes into the picture.

More technically, An SBOM is a structured list of components, modules, and libraries that are included in a given piece of software. However, there are many different meanings of an SBOM in the ecosystem. In the most basic form, think of them as a list of ingredients that evolves throughout the software development lifecycle as you add new code or components. Knowing about our software’s dependencies, we can first determine if we are impacted when a new security vulnerability is found. If so, we can apply security patches to mitigate the risk of that vulnerability before affecting our software.

Organizations can and do create and publish a software bill of materials in several different formats. In addition to these common formats, several methods are explicitly designed for delivering SBOMs, including SPDX (Software Package Data Exchange), Software Identification (SWID) Tags, and Cyclone DX, many open-source tools exist, such as Syft from Anchore, which is what we are going to talk about in this blog post, kubernetes-sigs/bom from Kubernetes SIG Release, cyclonedx-cli from CycloneDX, spdx-sbom-generator, Tern, and many more…

Let’s look at what we have to do successfully to generate an SBOM in GoReleaser using Syft. We’ll be setting up the demo on the GitHub Actions platform so that some examples might be specific to that platform.

🚨 TLDR; you can find all the source code what we are going to show you as an example on GitHub here.

Since GoReleaser uses Syft by calling it’s binary, we ensure that Syft binary exists before running GoReleaser. We can download the binary and move it to the executable’s path while running the job, but there is a better way of doing this, anchore/sbom-action. A sbom-action is a GitHub Action for creating a software bill of materials using Syft, but we can use its sub-action called anchore/sbom-action/download-syft to download the executable only.

To install Syft, you need to add the following line to our GitHub Action workflow.

- uses: anchore/sbom-action/download-syft@v0.7.0 # installs syft

Next, we need to add a setting specific to configure SBOM generation to the GoReleaser configuration file .goreleaser.yml. I said configure because GoReleaser’s SBOM generation support is highly configurable. After all, it accepts commands to be run to generate an SBOM and arguments that will pass to the command, which makes GoReleaser can work with any SBOM generation tool, as we mentioned earlier, seamlessly.

# creates SBOMs of all archives and the source tarball using syft
# https://goreleaser.com/customization/sbom
# Two different sbom configurations need two different IDs
sboms:
 - id: archive
 artifacts: archive
 - id: source
 artifacts: source

When you do not specify any command, it will use syftas a command by default, as you can see here.

GoReleaser lets you cross-compile your Go binaries and package them in various formats, including container images or tarballs. Then, using some public services such as GitHub Releases and DockerHub to distribute them to customers or production systems With the rise of software supply chain attacks, ensuring the integrity between the artifacts (container images, blobs, etc.) we produce and consume becomes more critical. Integrity means ensuring an artifact is what it says it is. It also indicates the artifact we consume has not been tampered with since it was created and comes from a valid source, a trusted identity (a public key, a person, a company, or some other entity). Leveraging this workflow gives your users confidence that the container images from their container registry were the trusted code you built and published. One of the best ways of checking the integrity of an artifact and ensuring that if the artifact has been tampered with is to use a utility called cosign from Sigstore.

Sigstore is an open-source security project now sponsored by the OpenSSF, the Open Software Security Foundation, allowing developers to build, distribute, and verify signed software artifacts securely. Sigstore provides a cosign tool, enabling developers to build, distribute, and verify signed software artifacts securely.

Cosign supports several types of signing keys, such as text-based keys, cloud KMS-based keys or even keys generated on hardware tokens, and Kubernetes Secrets, which can all be generated directly with the tool itself, and also supports adding key-value annotations to the signature.

Luckily, GoReleaser has built-in support for signing blobs, container images by using cosign. The same rule for Syft applies here, too. GoReleaser uses cosign by calling it’s binary, which means that we should ensure that cosign binary exists before running GoReleaser. Thanks to the cosign-installer, a GitHub Action lets you download cosign binary.

To install cosign, you need to add the following line to our GitHub Action workflow.

- uses: sigstore/cosign-installer@v2.1.0 # installs cosign

To install cosign into your environment, please follow the installation link from official website. But if you are Mac user, you can start installing cosign via HomeBrew 👇
$ brew install cosign

You can start signing your artifacts by creating public/private key pairs with the generate-key-pair command. Then, you need to run the sign command with the private key you generated. But in today’s blog post, we’ll be talking about a unique concept in cosign called Keyless Signing, which means that we no longer need to generate public/private key pairs.

For more background on “keyless signing”, see blog posts on the Chainguard blog on Fulcio and keyless signing with EKS.

It’s important to note that another part of sigstore is Fulcio, a root CA that issues signing certificates from OIDC tokens, and Rekor, a transparency log for certificates issued by Fulcio. In October, we announced that Actions runs can get OIDC tokens from GitHub for use with cloud providers, including the public Fulcio and Rekor servers run by the sigstore project. You can sign your container images with the GitHub-provided OIDC token in Actions without provisioning or managing your private key. This is critically what makes signing so easy.

https://github.blog/2021-12-06-safeguard-container-signing-capability-actions/

To enable signing container images in GoReleaser, all you need to do is add these lines below.

Keyless signing is still an experimental feature in cosign, so, we should use a special environment variable to enable that support named COSIGN_EXPERIMENTAL.

# signs our docker image
# https://goreleaser.com/customization/docker_sign
docker_signs:
 - cmd: cosign
 env:
 - COSIGN_EXPERIMENTAL=1
 artifacts: images
 output: true
 args:
 - "sign"
 - "${artifact}"

On the other hand, you must add these lines below to enable signing container images in GoReleaser.

# signs the checksum file
# all files (including the sboms) are included in the checksum, so we don't need to sign each one if we don't want to
# https://goreleaser.com/customization/sign
signs:
 - cmd: cosign
 env:
 - COSIGN_EXPERIMENTAL=1
 certificate: "${artifact}.pem"
 args:
 - sign-blob
 - "--output-certificate=${certificate}"
 - "--output-signature=${signature}"
 - "${artifact}"
 artifacts: checksum
 output: true

Once you have all of these, you will end up having something like the following picture for your release:

Also, a successful release pipeline:

A GitHub Actions run

If you verify the container image you pushed to the ghcr.io, a verify command of cosign might help you verify the image’s signature.

$ COSIGN_EXPERIMENTAL=1 cosign verify ghcr.io/goreleaser/supply-chain-example:v1.2.0

If you verify the blob, checksums.txt, in this case, you need to download the signature, the certificate, and checksums.txt itself first.

$ COSIGN_EXPERIMENTAL=1 cosign verify-blob \
 --cert checksums.txt.pem \
 --signature checksums.txt.sig
 checksums.txt \
tlog entry verified with uuid: "e42743bbbc1d06058ff7705a00bdf5046d920ede73e1fec7f313d19f5f3513b8" index: 977012
Verified OK

Conclusion

GoReleaser always cares about the security of the artifacts it produces this is why it integrates with tools like cosign, Syft, etc., to mitigate the risks happening in software supply chains. As you can see from the examples we gave, it does that effortlessly by simply adding a bunch of new settings to your GoReleaser configuration file, which all happens behind the scenes without making it even more complex.

🍭 BONUS: Another important topic that gives you a confidence about the software’s integrity is Reproducible Builds, are a set of software development practices that create an independently-verifiable path from source to binary code, thanks to Carlos A. Becker, wrote a blogpost to explain it in detail, so, please do not forget to checkout it his blogpost to learn more about how GoReleaser can help you to achieve reproducibility👇

Here’s the link.

Reproducible Builds

Sat, 26 Mar 2022 00:00:00 +0000

GoReleaser can help you, to some extent, to have reproducible builds.

What are reproducible builds?

According to Reproducible-Builds.org:

A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.

So, things we need to pay attention here are:

the source is the same
the dependencies are the same, in the same versions
chtimes are the same
build path is the same
any other tools needed to compile must be the same, in the same versions

While this might sound complicated, rest assured GoReleaser can help you with most of these items!

Reproducible Builds with GoReleaser

GoReleaser will by default inject a ldflag with the current timestamp as main.date, which you can use to display build time information. We will want to change that to use some fixed date, for instance, the date of the commit being built.

To avoid changes from one machine to another, we will also want to use -trimpath.

Finally, we’ll want to make sure the repo code haven’t changed, e.g., when building a tag, we want to make sure it wasn’t deleted and pushed again (i.e., moved).

We can achieve that with a config that looks like this:

builds:
 - env:
 - CGO_ENABLED=0
 goos:
 - linux
 - darwin
 goarch:
 - amd64
 - arm64
 mod_timestamp: "{{ .CommitTimestamp }}"
 flags:
 - -trimpath
 ldflags:
 - -s -w -X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{ .CommitDate }}

gomod:
 proxy: true

From now on, we basically only need to ensure the Go version is the same.

That’s out of the scope of GoReleaser’s scope, but easy enough to do in GitHub Actions by pinning to a specific version of Go.

So, there you have it: reproducible Go binary builds with GoReleaser!

Announcing GoReleaser v1.7 — The Go 1.18 release

Sun, 20 Mar 2022 00:00:00 +0000

The title would have been more creative if it was GoReleaser 1.18 as well… maybe… probably not.

Highlights

Go 1.18 update (#2978, #2984)
Ability to filter by file extension in HTTP uploads (#2992)
Homebrew tap service block (#2973)
Deprecated buildpacks support (#2982), and removed some deprecated code/etc that have been deprecated for 6 months+ (#2985)
As always, some dependency upgrades, bug fixes and documentation improvements.

You can see the full changelog here.

Other news

Still no community meeting, sorry 🫠. Link.
GoReleaser now has ~9.8k stars and 269 contributors! Thanks, everyone!
Our Discord server is getting new members almost daily. Join and chat with us!
nFPM also had a release as well, check it out.

GoReleaser: How To Distribute Your Binaries With Homebrew Or GoFish

Mon, 07 Mar 2022 00:00:00 +0000

This article is going to be a quick bite (or drink)! We going to discover, how fast we can create a Homebrew or GoFish deployment of our binaries with the help of GoReleaser.

But first, let us take a look into the concepts of the two package managers:

Homebrew 🍺

The Missing Package Manager for macOS (or Linux)

This statement is not from me, but from the official Homebrew website. Homebrew is similar to other package managers, like apt-get, aptitude, or dpkg. I will not go in this article into the details about Homebrew, but some terms are important to understand, as we going to use them in our .goreleaser.yaml file:

Tap: A Git repository of packages.

Formula: A software package. When we want to install new programs or libraries, we install a formula.

GoFish 🐠

GoFish, the Package Manager 🐠

GoFish is a cross-platform systems package manager, bringing the ease of use of Homebrew to Linux and Windows. Same as with Homebrew, I am not going into detail of GoFish but we need also here some understanding of the GoFish terminology:

Rig: A git repository containing fish food.

Food: The package definition

The example code

For each package manager, you should create its own GitHub repository. You can name it as you please, but i prefer to add the meaning of the repository.

goreleaser-rig for GoFish
goreleaser-tap for Homebrew

Add following snippet for GoFish support, to your existing .goreleaser.yaml:

rigs:
 - rig:
 owner: dirien
 name: goreleaser-rig
 homepage: "https://github.com/dirien/quick-bites"
 description: "Different type of projects, not big enough to warrant a separate repo."
 license: "Apache License 2.0"

And for Homebrew, add this little snippet:

brews:
 - tap:
 owner: dirien
 name: goreleaser-tap
 folder: Formula
 homepage: "https://github.com/dirien/quick-bites"
 description: "Different type of projects, not big enough to warrant a separate repo."
 license: "Apache License 2.0"

That’s all for now, and as usual with GoReleaser you can head over to the great documentation for more advanced settings:

https://goreleaser.com

Now run the release process and you will see this in your logs:

 • homebrew tap formula
• pushing formula=Formula/goreleaser-brew-fish.rb repo=dirien/goreleaser-tap
• gofish fish food cookbook
• pushing food=Food/goreleaser-brew-fish.lua repo=dirien/goreleaser-rig

Perfect! Everything works as expected.

We can check the content on the GitHub UI.

Installation

Now we can add the tap and the rig on our clients

Homebrew

brew tap dirien/goreleaser-tap
brew install goreleaser-brew-fish

GoFish

gofish rig add https://github.com/dirien/goreleaser-rig
gofish install github.com/dirien/goreleaser-rig/goreleaser-brew-fish

The End

Now you can distribute this tap or rig repositories and everybody can install your projects via this package manager.

The Code

You can find the demo code in my repository, to see some more details: dirien/quick-bites.

Announcing GoReleaser v1.6 — the boring release

Sun, 06 Mar 2022 00:00:00 +0000

GoReleaser 1.6 is out! Another “boring” release with some miscellaneous improvements and bug fixes.

Highlights

New filter and reverseFilter template functions (#2924)
nFPM and archiving in tar.gz should now be faster (#2940, #2941)
More Snapcraft app metadata fields (#2955)
New .TagBody template field (#2923)
Install amd64 binaries when no arm64 binaries are present on macOS (i.e. use Rosetta) (#2939)
Several dependency updates
Several bug fixes
Some documentation improvements

You can see the full changelog here.

Other news

I’m risking sounding repetitive here, but we still don’t have a new date for our first community call. Personal life a little too busy lately, will try my best to schedule it ASAP. Link.
GoReleaser now has ~9.7k stars and 268 contributors! Thanks, everyone!
Our Discord server is getting new members almost daily. Join and chat with us!
nFPM also had a release as well, check it out.

GoReleaser – Blog

Announcing GoReleaser v2.15

Flatpak

Go build ./... and better defaults

Generate completions in Homebrew Casks

Source RPMs

New website

Before publish installer types and SBOM support

Other updates

Other news

Download

Helping out

Goodbye, Mkdocs

Announcing GoReleaser v2.14

GitHub Secure Open Source Func

Finally, air-gapped license checks

Better changelogs

macOS .pkg installers

Windows installers

Docker v2 improvements

Homebrew Casks

Dynamically linked binaries

Better, safer, output

Deprecations

GitHub Action

Other updates

Other news

Download

Helping out

How GoReleaser strengthened security through GitHub's Secure Open Source Fund

Go is a solid platform, actually

Looking forward

Announcing GoReleaser v2.13

GitHub Universe and GoLab Firenze

All about MCP

GoReleaser Pro

Dockers v2

Other highlights

Other news

Download

Helping out

Upgrading to Cosign v3

What Changed

Updating Your GoReleaser Configuration

Verifying Signatures

Try It Out

Announcing GoReleaser v2.12

Docker v2

How it works

How to use it?

Makeself

Attestations

Smarter semver tag sorting

Other highlights

Other news

Download

Helping out

Announcing GoReleaser v2.11

Other news

Download

Helping out

Announcing GoReleaser v2.10

Homebrew Casks

MCP server

Other smaller changes

Other news

Download

Upgrading with Homebrew

Helping out

Announcing GoReleaser v2.9

Python builds

Other smaller changes

Gophercon LATAM

Other news

Download

Helping out

Announcing GoReleaser v2.8

New Package Repository Features

Publish to NPM

Native macOS DMG signing and notarizing

Go build `./...` and better defaults

macOS `.pkg` installers