GoReleaser builds Go binaries as fast and easily as possible

Describe the bug

Every release I do, I get a list of every commit despite using a simple semver version. I manually edit the commits down each time.

To Reproduce

I release using this file.

Expected behavior

I expect it to pick up commits since the last released version.

Environment (please complete the following information):

• OS: mac
• OS version: Darwin theganyo-macbookpro2.roam.corp.google.com 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
• GoReleaser Version 0.104.0, commit 7c4352147b6d9636f13d2fc633cfab05d82d929c, built at 2019-03-20T02:18:40Z

Is your feature request related to a problem? Please describe. It is not related to a problem. It's a feature request for signing and verifying with Keyless Mode.[^1]

Describe the solution you'd like

GoReleaser can use the cosign tool as a command in the sigs section. In order to enable Keyless mode in cosign, we need to pass an environment variable called COSIGN_EXPERIMENTAL=1. So, we've opened another issue to enable passing environment variables to the sigs section. Also, recently, the Kyverno project did the same thing. [^2]

[ ] - https://github.com/goreleaser/goreleaser/issues/2657 - @Dentrax

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context [^1]: https://github.com/sigstore/cosign/blob/main/KEYLESS.md [^2]: github.com/kyverno/kyverno/pull/2677

cc: @dentrax @erkanzileli

As @bernardoVale mentioned #on Slack it would be nice to support releasing to GitLab. There is a Go package for the API https://github.com/xanzy/go-gitlab. Since we also plan on adding Bintray support in #15 we might be able to combine some of the releasing logic.

Refactor of the context package.

We now have an artifact package.

We now have an artifact type which can be filtered anywhere in the code, as well as filter compositions. With this set of features, we dont need specific fields for each type of artifact.

The mutex also is in the artifact package, and we have an Artifacts type, which contains both the slice and the mutex, and also have the Add, List and Filter methods.

I end up fixing some thing I found along the way and/or didn't work at all before:

• docker ims from binary releases
• multiple darwin amd64 builds on homebrew
• Path now is always the full path (dist + folder + artifact) - before some pipes were using it differently and we have several filepath.Join(dist, artifact.Path) or similar around
• the artifactory pipe was greatly simplified due to the previous changes
• brew and artifactory pipes had some missing test cases which were added
• the build pipe no longer needs to know anything about naming templates (it was a hidden dependency)
• improved docs in several places

I also have placed several TODOs and opened a few issues to cover problems I've found.

This patch should allow us to add more types of artifacts easily, since all fields can be available.

I also included an Extra field which is a map[string]string, so some pipes can add additional info (right now only the build pipe is using it).

closes #455 closes #449

What happened?

When doing a release with S3 my credentials were not set properly. goreleaser ran to completion and did not raise any errors that the S3 uploads fail.

How can we reproduce this?

1. Create a .goreleaser.yml that uploads to an S3 bucket.
2. Remove credentials that give write access to that bucket
3. Run goreleaser

This should run to completion without alerting that the S3 uploads failed.

goreleaser version

goreleaser version 0.183.0
commit: be6199f08167cc85b0b16cefc02d8106237853b1
built by: homebrew

https://goreleaser.com

GoReleaser Check

• [X] goreleaser check shows no errors

Search

• [X] I did search for other open and closed issues before opening this.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Additional context

No response

Describe the bug

Since the new RPM code in nfpm and goreleaser 0.120.x was introduced it is no longer possible to push RPMs to packagecloud.io.

Packagecloud support response:

This package is missing a lot of required RPM headers that must appear in the YUM metadata so that YUM can find this package and install it from a repository.

I would suggest that the maintainer of this package spend some time reviewing the RPM documentation and/or requesting the tool they use for generating the RPM automatically all required RPM headers. There's lots of possible malformed RPM packages that will make our system 500; we catch a lot of the cases, but we do miss a few and will still 500 in some rare, isolated cases (like this package, which is significantly malformed).

To Reproduce

Steps to reproduce the behavior:

It should be possible to reproduce this bug locally from the https://github.com/pantheon-systems/pauditd project:

git clone [email protected]:pantheon-systems/pauditd.git
cd pauditd

curl -sL https://git.io/goreleaser | bash -s -- --snapshot --rm-dist

push to an existing packagecloud.io repo:

$ package_cloud push xxx/xxx/el/8 dist/*rpm

Looking for repository at xxx/xxx... success!
Pushing dist/pauditd-v1.1.11-next-1572710235-x86_64.rpm... Traceback (most recent call last):
        23: from /usr/local/bin/package_cloud:22:in `<main>'
        22: from /usr/local/bin/package_cloud:22:in `load'
        21: from /usr/local/lib/ruby/gems/2.6.0/gems/package_cloud-0.3.05/bin/package_cloud:4:in `<top (required)>'
        20: from /usr/local/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
        19: from /usr/local/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
        18: from /usr/local/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
        17: from /usr/local/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
        16: from /usr/local/lib/ruby/gems/2.6.0/gems/package_cloud-0.3.05/lib/package_cloud/cli/entry.rb:108:in `push'
        15: from /usr/local/Cellar/ruby/2.6.5/lib/ruby/2.6.0/benchmark.rb:293:in `measure'
        14: from /usr/local/lib/ruby/gems/2.6.0/gems/package_cloud-0.3.05/lib/package_cloud/cli/entry.rb:168:in `block in push'
        13: from /usr/local/lib/ruby/gems/2.6.0/gems/package_cloud-0.3.05/lib/package_cloud/cli/entry.rb:168:in `each'
        12: from /usr/local/lib/ruby/gems/2.6.0/gems/package_cloud-0.3.05/lib/package_cloud/cli/entry.rb:178:in `block (2 levels) in push'
        11: from /usr/local/Cellar/ruby/2.6.5/lib/ruby/2.6.0/benchmark.rb:293:in `measure'
        10: from /usr/local/lib/ruby/gems/2.6.0/gems/package_cloud-0.3.05/lib/package_cloud/cli/entry.rb:182:in `block (3 levels) in push'
         9: from /usr/local/lib/ruby/gems/2.6.0/gems/package_cloud-0.3.05/lib/package_cloud/cli/entry.rb:242:in `create_package'
         8: from /usr/local/lib/ruby/gems/2.6.0/gems/package_cloud-0.3.05/lib/package_cloud/repository.rb:52:in `create_package'
         7: from /usr/local/lib/ruby/gems/2.6.0/gems/rest-client-2.0.2/lib/restclient/request.rb:52:in `execute'
         6: from /usr/local/lib/ruby/gems/2.6.0/gems/rest-client-2.0.2/lib/restclient/request.rb:145:in `execute'
         5: from /usr/local/lib/ruby/gems/2.6.0/gems/rest-client-2.0.2/lib/restclient/request.rb:715:in `transmit'
         4: from /usr/local/Cellar/ruby/2.6.5/lib/ruby/2.6.0/net/http.rb:920:in `start'
         3: from /usr/local/lib/ruby/gems/2.6.0/gems/rest-client-2.0.2/lib/restclient/request.rb:725:in `block in transmit'
         2: from /usr/local/lib/ruby/gems/2.6.0/gems/rest-client-2.0.2/lib/restclient/request.rb:809:in `process_result'
         1: from /usr/local/lib/ruby/gems/2.6.0/gems/rest-client-2.0.2/lib/restclient/abstract_response.rb:103:in `return!'
/usr/local/lib/ruby/gems/2.6.0/gems/rest-client-2.0.2/lib/restclient/abstract_response.rb:223:in `exception_with_response': 500 Internal Server Error (RestClient::InternalServerError)

Additional context

Workaround is to use goreleaser v0.119.3, the last release before the nfpm rpm refactor.

Apologies I cannot provide more details at this time. If I am able to determine anything helpful I'll update this thread.

I would like go-releaser to support releasing multi-platform docker images using something like https://github.com/estesp/manifest-tool

This way, if the project is being built for multiple platforms, we will only use a single docker repository.

What happened?

      • uploading to release                         file=/Users/blacktop/Developer/Github/blacktop/ipsw/dist/ipsw_3.1.200_macOS_arm64.tar.gz.sbom name=ipsw_3.1.200_macOS_arm64.tar.gz.sbom
      • failed to upload artifact, will retry        artifact=ipsw_3.1.200_aarch64.apk error=POST https://uploads.github.com/repos/blacktop/ipsw/releases/84405069/assets?name=ipsw_3.1.200_aarch64.apk: 404 Not Found [] try=1
      • uploading to release                         file=dist/ipsw_3.1.200_aarch64.apk name=ipsw_3.1.200_aarch64.apk
      • uploading to release                         file=/Users/blacktop/Developer/Github/blacktop/ipsw/dist/ipsw_3.1.200_ios_arm64.tar.gz.sbom name=ipsw_3.1.200_ios_arm64.tar.gz.sbom
      • uploading to release                         file=/Users/blacktop/Developer/Github/blacktop/ipsw/dist/ipsw_3.1.200_macOS_x86_64.tar.gz.sbom name=ipsw_3.1.200_macOS_x86_64.tar.gz.sbom
      • uploading to release                         file=/Users/blacktop/Developer/Github/blacktop/ipsw/dist/ipsw_3.1.200_linux_arm64.tar.gz.sbom name=ipsw_3.1.200_linux_arm64.tar.gz.sbom
      • uploading to release                         file=/Users/blacktop/Developer/Github/blacktop/ipsw/dist/ipsw_3.1.200_macOS_arm64_extras.tar.gz.sbom name=ipsw_3.1.200_macOS_arm64_extras.tar.gz.sbom
      • uploading to release                         file=/Users/blacktop/Developer/Github/blacktop/ipsw/dist/ipsw_3.1.200_linux_x86_64.tar.gz.sbom name=ipsw_3.1.200_linux_x86_64.tar.gz.sbom
      • uploading to release                         file=/Users/blacktop/Developer/Github/blacktop/ipsw/dist/ipsw_3.1.200_macOS_x86_64_extras.tar.gz.sbom name=ipsw_3.1.200_macOS_x86_64_extras.tar.gz.sbom
      • uploading to release                         file=/Users/blacktop/Developer/Github/blacktop/ipsw/dist/ipsw_3.1.200_macOS_universal.tar.gz.sbom name=ipsw_3.1.200_macOS_universal.tar.gz.sbom
      • uploading to release                         file=dist/checksums.txt name=checksums.txt
      • uploading to release                         file=dist/checksums.txt.sig name=checksums.txt.sig
      • failed to upload artifact, will retry        artifact=ipsw_3.1.200_aarch64.apk error=POST https://uploads.github.com/repos/blacktop/ipsw/releases/84405069/assets?name=ipsw_3.1.200_aarch64.apk: 404 Not Found [] try=1
      • uploading to release                         file=dist/ipsw_3.1.200_aarch64.apk name=ipsw_3.1.200_aarch64.apk
      • failed to upload artifact, will retry        artifact=ipsw-3.1.200.aarch64.rpm error=POST https://uploads.github.com/repos/blacktop/ipsw/releases/84405069/assets?name=ipsw-3.1.200.aarch64.rpm: 404 Not Found [] try=1

How can we reproduce this?

run make release in my ipsw project

goreleaser version

❯ goreleaser -v
goreleaser version 1.13.1
commit: b0ffc7af05aa391b766e8e26f5ad5ec37c640d6e
built at: 2022-11-29T01:03:51Z
built by: goreleaser
goos: darwin
goarch: arm64
module version: v1.13.1, checksum: h1:9yTCn5UE3+1wNtVB3ybUAwjioLq79UyfGz8D+iPOcRk=

https://goreleaser.com

GoReleaser Check

• [X] goreleaser check shows no errors

Search

• [X] I did search for other open and closed issues before opening this.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Additional context

I did search for other open and closed issues before opening this, but this isn't just the 422 Validation Failed [{Resource:ReleaseAsset Field:name Code:already_exists Message:}] but also WHY is nfpm making aarch64 pkgs all of the sudden?

ipsw_3.1.200_aarch64.apk: 404 Not Found could that have something to do with it? I've tried using a pre-1.13 version of goreleaser, I've tried using a VPN and my phone as a hotspot to factor out internet and get the same issues.

Hi @caarlos0,

We've been pleased to integrate goreleaser into our release process for https://github.com/fleetdm/fleet/. In particular, making it easy to build all the necessary artifacts and upload in GitHub Actions has helped with my goal to improve transparency and address software supply chain integrity issues (discussed nicely in https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html).

We are merging a couple of our repos, and purchased an enterprise license for GoReleaser Pro to support the project and utilize the monorepo functionality. I only just discovered that the goreleaser pro features are not open-source/source-available and require utilizing a separate binary. This conflicts with our goals to increase transparency and integrity in the full lifecycle of our software by adding an un-auditable dependency (GoReleaser Pro) into the build process.

Would you consider making the code source-available? I know this is a big ask, and it's something that we have contemplated quite a bit for our business. We've settled on making everything source-available using a license that is inspired by GitLab's License.

Otherwise we may need to find ways to work around using GoReleaser Pro features in order to move forward with transparency in our build tooling.

Thank you for the consideration.

Add support for Gitea in release pipe

I (and probably many others) want to create releases and upload artifacts to their Gitea instances.

Gitea: https://gitea.io/en-us/ Gitea Go SDK: https://godoc.org/code.gitea.io/sdk/gitea

closes #1106

This is an early prototype of a solution for #1328 to solicit early feedback.

Usage

builds:
  -
    env:
      - CGO_ENABLED=0
    targets:
      - darwin_amd64
      - windows_386
      - windows_amd64
    after:
      all:
        hooks:
          - zip ./signable_binaries.zip {{ range .Builds }} {{ .Path }}{{ end }}
          - echo "Signing every eligible binary..."
          - cmd: ./codesign.sh
            env:
              - ZIP_FILE={{ .ProjectName }}_{{ .Version }}_{{ .Target }}.zip
      each:
        default_dir: "{{ .Path }}"
        hooks:
          - upx {{ .Name }}

I would be happy to add some tests, perhaps some more logging and docs if we agree on the rough direction.

To help solve this issue

    apk:
      signature:
        key_file: "{{ .Env.ABUILD_KEY_NAME }}.rsa"
        key_name: "{{ .Env.ABUILD_KEY_NAME }}"

Allow that the key_name in apk signature to be templated

The name of the key might not be hardcoded, in a github workflow

...

continuing the PR by @developer-guy

• [x] should be a publisher, as it does publish the images it builds every time
• [x] Default method does not work
• [x] the fromConfig thing should probably be on the defaults, too
• [x] wire --skip-ko
• [x] documentation
• [x] more tests
• [x] use same registry as docker tests does
• [ ] see if we can make the log output match goreleaser's
• [ ] ??

closes #2556 closes #3490

not sure how useful this is... but might help with mental models everyone has (including me), both for contributing and using goreleaser...

I also thought about splitting it into multiple svgs, e.g.:

• goreleaser phases ( prep , build, archive, publish etc)
• one for each phase as well
  • especially the publish phase, which does quite a lot of things

wdyt?

PS: if we do use this, I'll put it inside the docs folder somewhere...

Is your feature request related to a problem? Please describe.

Right now, per https://goreleaser.com/cookbooks/build-go-modules/ and gomod_proxy.go, you roughly do:

• Create a temporary directory
• Drop a templated main.go file
• Drop a templated go.mod file with require main_module_path git_tag
• Copy go.sum from the original module
• Run go mod tidy
• Run go build main_package_path

You could accomplish the same with fewer steps. In particular, you don't need a main.go file, and you don't need to have a tidied module either. You could instead do:

• Create a temporary directory
• Run go mod init test, or use a template to get the same plain go.mod file
• Copy go.sum from the original module
• Run go get main_module_path@git_tag
• Run go build main_package_path

Beyond being one file and step less, this is also more powerful: you can use any VCS reference in go get module@version, including git commit hashes, git branch names, etc.

Also note that you don't strictly need to copy go.sum; it will still work without that step, and I reckon you don't lose any safety thanks to GOSUMDB. Though I guess you avoid a few network roundtrips if go.sum already has most of the hashes needed.

Describe the solution you'd like

Just suggesting a perhaps slightly better way of implementing builds via the proxy :)

Describe alternatives you've considered

Search

• [X] I did search for other open and closed issues before opening this.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Additional context

No response

Add ability for brew repos to have an arbitrary git repo as a publish target.

Adds configuration parameters in the RepoRef config for git urls

- name: "{{ .ProjectName }}"
    description: "My Tool Description"
    folder: Formulas
    tap:
      branch: main
      name: private-brew-tap
      git_url: "https://mygiturl.myurl.com/repo.git"
      private_key: "{{ .Env.SSH_KEY }}"

It does not effect the function of other pipes that use RepoRef without more work to explicitly use the added fields

To make it easier to push formulas for private git repositories

#3525 ...

What happened?

The nightly release doesn't get published even though publish_release is set to true. It creates a draft release without publishing it on GitHub.

How can we reproduce this?

nightly:
  name_template: "{{ .ShortCommit }}-devel"
  publish_release: true
  keep_single_release: true
  tag_name: nightly

goreleaser version

goreleaser v1.12.3-pro

GoReleaser latest installed successfully
/opt/hostedtoolcache/goreleaser-action/1.12.3-pro/x64/goreleaser release --rm-dist --nightly
  • by using this software you agree with its EULA, available at https://goreleaser.com/eula
  • running goreleaser v1.12.3-pro
  • starting release...
  • loading config file                              file=.goreleaser.yml
  • loading environment variables
  • getting and validating git state
    • building...                                    commit=8341c17e16fea093856c9432439e97d72e57d3a7 latest tag=v3.3.0
    • pipe skipped                                   reason=validation is disabled
  • parsing tag
  • setting defaults
  • running before hooks
    • running hook                                   hook=rm -rf static
    • running hook                                   hook=go run .
    • took: 42s
  • nightly
    • building nightly...                            version=8341c17-devel
  • checking distribution directory
  • loading go mod information
  • build prerequisites
  • writing effective config file
    • writing                                        config=dist/config.yaml
  • adjusting internal git state
  • generating changelog
    • writing                                        changelog=dist/CHANGELOG.md
  • building binaries
    • skip is set                                    id=PROJECT
  • archives
    • creating                                       archive=dist/PROJECT-devel.tar.gz
    • took: 1s
  • calculating checksums
  • storing release metadata
    • writing                                        file=dist/artifacts.json
    • writing                                        file=dist/metadata.json
  • publishing
    • scm releases
      • creating or updating release                 repo=USER/PROJECT tag=8341c17e16fea093856c9432439e97d72e57d3a7
      • deleted previous nightly pre-release         commit=main name=e393ee05486deccd8be8d78c71a9fafe6c7fbbea tag=nightly
      • deleted previous nightly tag
      • uploading to release                         file=dist/PROJECT-devel_checksums.txt name=PROJECT-devel_checksums.txt
      • uploading to release                         file=dist/PROJECT-devel.tar.gz name=PROJECT-devel.tar.gz
      • published                                    url=https://github.com/USER/PROJECT/releases/tag/nightly
      • took: 4s
  • took: 4s
  • release succeeded after 47s
  • thanks for using goreleaser-pro!

GoReleaser Check

• [X] goreleaser check shows no errors

Search

• [X] I did search for other open and closed issues before opening this.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Additional context

No response