Use goreleaser to build releases and also publish Homebrew formula

[mrnugget]

I discovered GoReleaser a few days ago when I found out that Github's new gh CLI is automatically released as a Homebrew formula: https://github.com/github/homebrew-gh

That would be really nice to have. Now, I'm not sure whether the config here works as intended.

Doing a dry-run release locally seems to work:

 goreleaser --snapshot --skip-publish --rm-dist

   • releasing using goreleaser 0.126.0...
   • loading config file       file=.goreleaser.yml
   • RUNNING BEFORE HOOKS
      • running go mod download
      • running go mod tidy
   • LOADING ENVIRONMENT VARIABLES
      • pipe skipped              error=publishing is disabled
   • GETTING AND VALIDATING GIT STATE
      • releasing 3.10.8, commit f907940b61d30be8c115c8f0940e48c9dda556e8
      • pipe skipped              error=disabled during snapshot mode
   • PARSING TAG
   • SETTING DEFAULTS
      • LOADING ENVIRONMENT VARIABLES
      • SNAPSHOTING
      • GITHUB/GITLAB/GITEA RELEASES
      • PROJECT NAME
      • BUILDING BINARIES
      • ARCHIVES
      • LINUX PACKAGES WITH NFPM
      • SNAPCRAFT PACKAGES
      • CALCULATING CHECKSUMS
      • SIGNING ARTIFACTS
      • DOCKER IMAGES
      • ARTIFACTORY
      • BLOB
      • HOMEBREW TAP FORMULA
         • optimistically guessing `brew[0].installs`, double check
      • SCOOP MANIFEST
   • SNAPSHOTING
   • CHECKING ./DIST
      • --rm-dist is set, cleaning it up
   • WRITING EFFECTIVE CONFIG FILE
      • writing                   config=release/config.yaml
   • GENERATING CHANGELOG
      • pipe skipped              error=not available for snapshots
   • BUILDING BINARIES
      • building                  binary=/Users/thorstenball/work/src-cli/release/src-cli_windows_amd64/src.exe
      • building                  binary=/Users/thorstenball/work/src-cli/release/src-cli_darwin_amd64/src
      • building                  binary=/Users/thorstenball/work/src-cli/release/src-cli_linux_amd64/src
   • ARCHIVES
      • creating                  archive=release/src-cli_3.10.8-SNAPSHOT-f907940_windows_amd64.tar.gz
      • creating                  archive=release/src-cli_3.10.8-SNAPSHOT-f907940_darwin_amd64.tar.gz
      • creating                  archive=release/src-cli_3.10.8-SNAPSHOT-f907940_linux_amd64.tar.gz
   • LINUX PACKAGES WITH NFPM
   • SNAPCRAFT PACKAGES
   • CALCULATING CHECKSUMS
      • checksumming              file=src-cli_3.10.8-SNAPSHOT-f907940_darwin_amd64.tar.gz
      • checksumming              file=src-cli_3.10.8-SNAPSHOT-f907940_linux_amd64.tar.gz
      • checksumming              file=src-cli_3.10.8-SNAPSHOT-f907940_windows_amd64.tar.gz
   • SIGNING ARTIFACTS
      • pipe skipped              error=artifact signing is disabled
   • DOCKER IMAGES
      • pipe skipped              error=docker section is not configured
   • PUBLISHING
      • pipe skipped              error=publishing is disabled
   • release succeeded after 2.71s

But that also includes the snapshots and I'm mostly concerned about the Travis CI configuration.

I moved the secret token from the deply configuration to the global env vars, since goreleaser expects a GITHUB_TOKEN env var, but since I don't have an encryption key, I'm not sure what's in the secret (cc @slimsag)

[unknwon]

Looks cool, never used so can't say much :D

[keegancsmith]

I also tried it out a little bit back. Its a fun bit a of software. Will take a look at this PR. sourcegraph/docsite#36

[mrnugget]

One "downside" seems to be that goreleaser always packages the binary in an archive. That would make the installation instructions a bit longer plus break the existing "forward to newest version" behavior in sourcegraph/sourcegraph. cc @efritz

[efritz]

Do you mean this place publishes releases to the page in a tar archive instead of raw binaries?

[mrnugget]

Yes, exactly. Take a look at GitHub's cli/cli releases page: https://github.com/cli/cli/releases This was populated by goreleaser.

[efritz]

If they need to be packaged that's a bit of an issue. Old instances will now not be able to download new patch releases if they're deployed this way. New instances could untar them and return just the raw binary.

Thoughts on how to go forward?

[keegancsmith]

I managed to work this out for docsite: https://github.com/sourcegraph/docsite/blob/master/.goreleaser.yml see the release here https://github.com/sourcegraph/docsite/releases/tag/v1.4.0

[emidoots]

I moved the secret token from the deploy configuration to the global env vars, since goreleaser expects a GITHUB_TOKEN env var, but since I don't have an encryption key, I'm not sure what's in the secret (cc @slimsag)

It's the Travis deployment API key which allows it to upload files to https://github.com/sourcegraph/src-cli/releases

I am generally against complicating the installation instructions, our tooling should serve to make installation easier and I don't see a particularly good reason to make that more complicated (after all, we can always use goreleaser and just unarchive/rename the binaries to not include a version number prior to uploading them to GitHub).

[mrnugget]

It's the Travis deployment API key which allows it to upload files to https://github.com/sourcegraph/src-cli/releases

I know why it's there 😄 I'm just not clear on what exactly is in there. Is it the key itself, i.e. just foobar? Or is it something like GITHUB_TOKEN=foobar?

am generally against complicating the installation instructions, our tooling should serve to make installation easier and I don't see a particularly good reason to make that more complicated (after all, we can always use goreleaser and just unarchive/rename the binaries to not include a version number prior to uploading them to GitHub).

Agree with that stance. And it's also the motivation behind me looking into this, since moving to goreleaser would make it possible to just brew install sourcegraph/src-cli/src-cli.

What exactly are you concerned about? That we complicate the instructions if we add a tar.gz file? If so, @keegancsmith's last comment makes me think that we can fix that and just continue to release binaries :)

[emidoots]

I'm just not clear on what exactly is in there. Is it the key itself, i.e. just foobar? Or is it something like GITHUB_TOKEN=foobar?

Got it, unfortunately I don't know either. I think it's just foobar but I could be wildly wrong. I remember following some official Travis tutorial for uploading to the releases page. In any case, it should be easy to generate a new one for whatever you need.

What exactly are you concerned about? That we complicate the instructions if we add a tar.gz file? [...]

Yes. In short, as long as the current installation commands remain the same I am happy 👍If there are changes to those I would like to review them.

[mrnugget]

Just tried this out with @slimsag to release a new version. It worked! Will merge this and cut a new release.