v3 wish list

[caarlos0]

Hey GoReleaser community!

I started to work on v2 v3, which will have breaking changes... so, if you have suggestions, the time is now!

Throw here your wishes for goreleaser v2+, even if it breaks old configurations 🙏

[ryancurrah]

• Custom publish artifacts by package type (deb, rpm, docker, etc). Or some sort of custom filter that has access to multiple properties.
• Configuration templates for sections to make it easier to manage hundreds of GoReleaser configurations.
• Splitting up artifact creation and artifact publishing configuration. So we have new top level sections, packages and publish. Creating an artifact and publishing are two different operations and being able to split it up and provide specific publish configuration for each artifact would make the publish operation more usable. Note: We currently do not use GoReleaser to publish any of our artifacts today, we use a make target.
• Build support for other languages, Python, Rust, etc. (Not a high priority but hey while we are wishing). The builds sections would look like builds.go[], builds.python[], builds.rust[]. Even if you don't want to support multiple languages right now, adding a subsection of go would allow for it in the future.

An issue we struggle with is making sweeping changes to the GoReleaser configuration across repositories. Most of our GoReleaser configurations are the same for builds, nfpms, dockers, etc. With the occasional extra file copied to a debian or docker image. One feature that would make my life wayyyy easier is to some how allow specifying a template to use, but still allow overriding specific parts. Something like...

For the template idea we would go from this...

builds:
  - id: acme-cli
    main: ./cmd/acme-cli
    binary: acme-cli
    flags:
      - -trimpath
    goos:
      - linux
      - darwin
      - windows
    goarch:
      - amd64
      - arm64
    env:
      - CGO_ENABLED=0
    
archives:
  - id: acme-cli
    name_template: '{{ replace .Binary "_" "-" }}_{{ .Version }}_{{ title .Os }}_{{- if eq .Arch "amd64" }}x86_64{{- else }}{{ .Arch }}{{ end }}{{- if .Arm }}v{{ .Arm }}{{ end }}'
    format_overrides:
      - goos: windows
        format: zip
    files:
      - none*
   
brews:
  - name: acme-cli
    ids:
      - acme-cli
    repository:
      owner: acme-cli
      name: homebrew-tap
    commit_author:
      name: goreleaserbot
      email: goreleaser@acme.com
    url_template: '{{ .Env.ARTIFACTS_BASE_URL }}/{{ .Env.ARTIFACTS_ARCHIVE_REPOSITORY }}/{{ .ProjectName }}/{{ .Version }}/{{ .ArtifactName }}'
    homepage: '{{ .GitURL }}'
    folder: Formula
    skip_upload: true

To this...

includes:
  - from_file:
      path: .goreleaser.templates.yml

builds:
  - id: acme-cli
    main: ./cmd/acme-cli
    binary: acme-cli
    template: cloud-cli-builds

archives:
  - id: acme-cli
    template: cloud-cli-archives

brews:
  - name: acme-cli
    ids:
      - acme-cli
    template: cloud-cli-homebrew

Then the template section might look like...

templates:
  builds:
    - id: cloud-cli-builds
      template:
        flags:
          - -trimpath
        goos:
          - linux
          - darwin
          - windows
        goarch:
          - amd64
          - arm64
        env:
          - CGO_ENABLED=0

  archives:
    - id: cloud-cli-archives
      template:
        name_template: '{{ replace .Binary "_" "-" }}_{{ .Version }}_{{ title .Os }}_{{- if eq .Arch "amd64" }}x86_64{{- else }}{{ .Arch }}{{ end }}{{- if .Arm }}v{{ .Arm }}{{ end }}'
        format_overrides:
          - goos: windows
            format: zip
        files:
          - none*

  brews:
    - id: cloud-cli-homebrew
      template:
        repository:
          owner: acme-cli
          name: homebrew-tap
        commit_author:
          name: goreleaserbot
          email: goreleaser@acme.com
        url_template: '{{ .Env.ARTIFACTS_BASE_URL }}/{{ .Env.ARTIFACTS_ARCHIVE_REPOSITORY }}/{{ .ProjectName }}/{{ .Version }}/{{ .ArtifactName }}'
        homepage: '{{ .GitURL }}'
        folder: Formula
        skip_upload: true

This would allow us to fix most breaking changes in one file instead of hundreds.

[caarlos0]

Custom publish artifacts by package type (deb, rpm, docker, etc). Or some sort of custom filter that has access to multiple properties.

publishers.if shipping in 2.5 in few weeks!

[kishaningithub]

I would like to have godownloader i.e. publishing install scripts as an artifact as part of goreleaser

[chey]

Would be nice if there was an option to put the CHANGELOG somewhere else say, for example, in the git repository itself.

Would be useful for people using this tool with other platforms like BitBucket.

[dehanj]

I would like to have a fully polished, integrated sign and notarize workflow when building and creating packages for macos.
I know that it works today, but it is kind of a pain and not obvious.

I also know this has been discussed multiple times in different places, such as https://github.com/orgs/goreleaser/discussions/3350
And there a few options to use, as https://github.com/anchore/quill and of course Gon (which now has a new care taker, which is great!)

This is an important step for macos, so it would be nice if it is a polished part of goreleaser as well.

[caarlos0]

just added this #4774

[dehanj]

Thanks @caarlos0! Will test it out!

[ryancurrah]

@caarlos0 Have you considered my feature request for adding support for additional programming languages? Our team is planning to expand CI support beyond Go, and we see GoReleaser as a highly beneficial tool that could bring similar value to other languages.

[kishaningithub]

Implementing a tool like this for other languages is very difficult because other languages do not offer the beautiful cross compilation ergonomics like golang

[caarlos0]

yes, I've been experimenting with zig and rust (using zig to cross compile).

i don't have any timelines yet, as I'm dealing with some family matters, but probably next year only - if it works as I'm thinking it will 😄

[ryancurrah]

Awesome! We will be supporting Python soon so hoping to be able to create a wheel package and copy it to a Docker container.

[caarlos0]

for anyone that ends up here: rust and zig were shipped in v2.5 :)

[caarlos0]

Another thing I think would be good is a less repetitive API for docker images: https://github.com/orgs/goreleaser/discussions/5442

[ryan-latte]

I'd love to get a pkg builder for MacOS. I've had to hack together my own that uses a before_publish hook and then manually add its outputs to the release.

[caarlos0]

yeah, that's a good one!

can you share more details of how you're doing it? might be quick to implement 🤔

[ryan-latte]

I wrote a little go tool that:

1. Creates a dist/darwin/pkg directory
2. For each PKG I am creating (identified by reverse URI notation: com.example.app)
3. Create a directory tree matching where I want the resulting file in the filesystem (com.example.app/root/Library/Example/)
4. Create a scripts directory with the postinstall (com.example.app/scripts/postinstall) - this shell script must be present, even if empty.
5. Copy the binary and any other templated files into the directory tree (com.example.app/root/Library/Example/{my-app,uninstall.sh, etc.})
6. Shell out to pkgbuild --version V --scripts com.example.app/root/scripts --root com.example.app/root pkgs/com.example.app.pkg

Now I'll have a directory named pkgs with every pkg I'm building (it's recommended to have one for installing service plists, one for tools, one for the app itself, and so on for each major component).

Finally, I can build the main pkg:

1. Shell out to productbuild providing the --distribution DISTRIBUTION_FILE --resources Resources --package-path ./pkgs
2. The Distribution file is a plist that defines things like the license, the supported architectures, if the binary is universal or not, checking supported OS versions, which of the provided PKGs to install (and the order), that sort of thing.
3. The Resources folder is just anything else that the Distribution file references. For example, the distribution can provide an HTML file to be displayed when the installer starts or a conclusion HTML for when it's all done.

Finally, the finished PKG is located at pkg/app-name-version-sha.pkg and ready for uploading to a release.

[caarlos0]

this just landed on nightly btw - thanks!

[reyamir]

+1 for flatpak support

[caarlos0]

for reference: #2927

[Propfend]

I would love some way to publish my artifacts without necessarily building it using goreleaser:

https://github.com/orgs/goreleaser/discussions/5788

[caarlos0]

You can import binaries

https://goreleaser.com/customization/prebuilt/

On that other discussion I thought you wanted to run specific steps in isolation, if that's no the case then importing binaries should work