goreleaser / goreleaser

Deliver Go binaries as fast and easily as possible

GoReleaser

Deliver Go binaries as fast and easily as possible.

---

GoReleaser builds Go binaries for several platforms, creates a GitHub release and then pushes a Homebrew formula to a tap repository. All that wrapped in your favorite CI.

---

Get GoReleaser

• On your machine;
• On CI/CD systems.

Documentation

Documentation is hosted live at https://goreleaser.com

Community

You have questions, need support and or just want to talk about GoReleaser?

Here are ways to get in touch with the GoReleaser community:

You can find the links above and all others here.

Code of Conduct

This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. We appreciate your contribution. Please refer to our contributing guidelines for further information.

Badges

GitHub Sponsors

High-tier sponsors of @caarlos0 on GitHub:

OpenCollective

Sponsors

Does your company use goreleaser? Help keep the project bug-free and feature rich by sponsoring the project.

Backers

Love our work and community? Become a backer.

Contributors

This project exists thanks to all the people who contribute. [Contribute].

Stargazers over time

goreleaser's Issues

create a website

I already started something at https://github.com/goreleaser/goreleaser.github.io, but it's ugly.

If someone wants to do this, let me know =)

ARM flags GOARM

• https://github.com/golang/go/wiki/GoArm

Supported architectures

Go supports the following ARM architectural families.

Architecture	Status	GOARM value	GOARCH value
ARMv4 and below	sorry, not supported	n/a	n/a
ARMv5	supported	GOARM=5	GOARCH=arm
ARMv6	supported	GOARM=6	GOARCH=arm
ARMv7	supported	GOARM=7	GOARCH=arm
ARMv8	supported	without GOARM	GOARCH=arm64

Starting from Go 1.1, the appropriate GOARM value will be chosen if you compile the program from source on the target machine. In cross compilation situations, it is recommended that you always set an appropriate GOARM value along with GOARCH.

Supported operating systems

• ARM on Linux. You must run an EABI kernel. These are generally known as armel for softfloat (compatible with ARMv5) or armhf for hardware floating point (ARMv6 and above).
• ARM on Darwin: ARMv7 is required.
• ARM on FreeBSD, OpenBSD, and NetBSD: ARMv6K or above is required.

---

arm

See https://golang.org/doc/install/source#environment

• GOARM=5: use software floating point; when CPU doesn't have VFP co-processor
• GOARM=6: use VFPv1 only; default if cross compiling; usually ARM11 or better cores (VFPv2 or better is also supported)
• GOARM=7: use VFPv3; usually Cortex-A cores

arm64

All ARMv8-A processors.

ppc64 (big endian)

"Big-endian 64-bit PowerPC (linux/ppc64) only requires the POWER5 architecture." (from
https://golang.org/doc/go1.7#ports)

ppc64le (little endian)

"The experimental port to Linux on little-endian 64-bit PowerPC (linux/ppc64le) now requires the POWER8 architecture or later." (from
https://golang.org/doc/go1.7#ports)

mips64 (big endian)

MIPS III or higher. Builder is using MIPS64r2.

mips64le (little endian)

MIPS III or higher in little endian mode. Builders are using Loongson 2E/2F.

s390x

z196+

mips (big endian) and mipsle (little endian)

MIPS32r1, with FPU or kernel FPU emulation

#goreleaser Slack channel

I create a Channel on https://gophers.slack.com/.
If you don't have an account you can join at https://invite.slack.golangbridge.org/.

This might be helpful for discussions and questions not fit for issues.

Maybe we can link to it in the readme?

Add a complete and commented goreleaser.yml.example

I was thinking, maybe instead of showing everything that can be done in the README, we can add a goreleaser.yml.example with every section and comment everything there...

Maybe wrap it a unit test to prevent it from being outdated...

Multiple Binaries / Path to source

So creating another issue based on my use-cases of goreleaser,
Ran into issue of getting goreleaser to work with whats-this/owo.go where I have owo.go/cmd/gowo, CLI application in a nested folder, goreleaser doesn't see it from root and fails to run because root directory which itself is the library doesn't have a main.go.

Currently to release gowo I had to copy license, create separate readme.md (would be nice to preserve this but not necessary) and move yml config for releaser to cmd/gowo.
But there would issue if I was to add additional tools aside from gowo (another folder in cmd for ex) as the archive would get overwritten (if at all committed, releaser errors if release already exists)

Basically what I would like to request is for either goreleaser to build all things ./... instead of just one
Or make it easier to add non-root main.go locations.

Sorry for giving so many requests but I really like this project and would love to see it support more use-cases

post-hook for modifying built binaries

Some projects package resources into binaries with the form of a zip file. Most trivially, this is done like this:

echo file.zip >> binary
zip -A binary

I digress about specifics, but the point is that packages like go.rice and others add this binary/zip data into executables built by go. The packaging/embedding of them differs a bit, alas some post hook would be nice if one wants to follow the docs.

check if file exists before trying to add it to the package?

upload to bintray

maybe it is a cool feature to add...

Brew releasing requires formula file to exist

Brew releasing only works when the formula file already exist in the specified Git repository.
I added an empty file to make it work.
I think the problem is the use of UpdateFile here: https://github.com/goreleaser/releaser/blob/master/pipeline/brew/brew.go#L74
Maybe we can consider using CreateFile when the updating fails?

Clarify usage of Git tags

The main use case for GoReleaser seems to be running it via CI for Git tags only.
However, nothing stops you from running it on any other branch.

By running it on another branch GoReleaser still uses the latest Git tag to name the release,
but for building it actually uses the source of the current active branch (if I don't miss anything here?).
Also, it's not possible to create a release that doesn't depend on a Git tag.

I would suggest to either always use the source of the latest tag
or to allow releasing without a relation to Git tags.

The first solution would require to get the source from the tag for building or to only allow building when the current branch is the latest tag.

The second solution would need more thinking about other scenarios for releasing Go projects.

Global config file

To help DRY up configuration, and to help with global options (perhaps a particular machine, developer expects to build mainly on ARM with BSD) I propose a global releaser.yml file.

It would look like:

github:
  token: github-token
build:
  oses:
    - freebsd
  arches:
    - amd64

Note the addition of a github token. This would allow the omission of the env var, and without the concern of committing it to source control given this file is outside of the repo.

It would introduce an order of precedence:

1. default values in releaser
2. global config
3. repo config
4. env vars/ cli args

`releaser --init`

Generate a skeleton releaser.yml file based on the origin remote of the repo.

This wont be a perfect tool; origin almost certainly wont point to the correct place when forking and working within GOROOT, but it ought to work well enough for new projects and to provide sensible values for CIs

add archive replacements support

as described in #13 (comment) and #13 (comment)

Build failed in travis when use goreleaser

This is log https://travis-ci.org/openatx/wdaproxy/builds/192289771

The command "go test -v ./..." exited with 0.
after_success
0.37s$ test -n "$TRAVIS_TAG" && curl -s https://raw.githubusercontent.com/goreleaser/get/master/latest | bash
Setting defaults...
Loading data from environment variables...
Gathering Git data...
Filling repositories data...
panic: runtime error: index out of range
goroutine 1 [running]:
panic(0x79c740, 0xc42000c160)
	/home/travis/.gimme/versions/go1.7.4.linux.amd64/src/runtime/panic.go:500 +0x1a1
github.com/goreleaser/goreleaser/pipeline/repos.split(0x0, 0x0, 0xc4200d8020, 0x7, 0xc4200d8028, 0x8)
	/home/travis/gopath/src/github.com/goreleaser/goreleaser/pipeline/repos/repos.go:34 +0x95
github.com/goreleaser/goreleaser/pipeline/repos.Pipe.Run(0xc4200156b0, 0xc42004d970, 0x45cac1)
	/home/travis/gopath/src/github.com/goreleaser/goreleaser/pipeline/repos/repos.go:24 +0xf7
github.com/goreleaser/goreleaser/pipeline/repos.(*Pipe).Run(0x9f2ef0, 0xc4200156b0, 0x1, 0x777b00)
	<autogenerated>:2 +0x56
main.main.func1(0xc420080500, 0xc420080500, 0xc42004dc47)
	/home/travis/gopath/src/github.com/goreleaser/goreleaser/main.go:61 +0x2e8
github.com/goreleaser/goreleaser/vendor/github.com/urfave/cli.HandleAction(0x784fe0, 0x83b138, 0xc420080500, 0xc42001a480, 0x0)
	/home/travis/gopath/src/github.com/goreleaser/goreleaser/vendor/github.com/urfave/cli/app.go:485 +0xd4
github.com/goreleaser/goreleaser/vendor/github.com/urfave/cli.(*App).Run(0xc42007cb60, 0xc42000c2e0, 0x1, 0x1, 0x0, 0x0)
	/home/travis/gopath/src/github.com/goreleaser/goreleaser/vendor/github.com/urfave/cli/app.go:259 +0x74f
main.main()
	/home/travis/gopath/src/github.com/goreleaser/goreleaser/main.go:69 +0x1dd

panic: Duplicated key '_' in struct config.ProjectConfig

Great project!
I'm trying to use it on my program which has a main.go, github.com/schollz/bol. My goreleaser.yml is:

repo: schollz/bol
binary_name: bol

and I keep getting an error:

$ releaser -c goreleaser.yml
panic: Duplicated key '_' in struct config.ProjectConfig [recovered]
        panic: Duplicated key '_' in struct config.ProjectConfig

goroutine 1 [running]:
panic(0x788c40, 0xc042005560)
        C:/Go/src/runtime/panic.go:500 +0x1af
gopkg.in/yaml%2ev1.handleErr(0xc0420918e0)
        C:/Go/work/src/gopkg.in/yaml.v1/yaml.go:28 +0x194
panic(0x788c40, 0xc042005560)
        C:/Go/src/runtime/panic.go:458 +0x251
gopkg.in/yaml%2ev1.(*decoder).mappingStruct(0xc042091898, 0xc04203e6c0, 0x7d9620, 0xc0420c20f0, 0x199, 0x0)
        C:/Go/work/src/gopkg.in/yaml.v1/decode.go:508 +0x507
gopkg.in/yaml%2ev1.(*decoder).mapping(0xc042091898, 0xc04203e6c0, 0x7d9620, 0xc0420c20f0, 0x199, 0x0)
        C:/Go/work/src/gopkg.in/yaml.v1/decode.go:461 +0x863
gopkg.in/yaml%2ev1.(*decoder).unmarshal(0xc042091898, 0xc04203e6c0, 0x7d9620, 0xc0420c20f0, 0x199, 0xc042091830)
        C:/Go/work/src/gopkg.in/yaml.v1/decode.go:261 +0x7b
gopkg.in/yaml%2ev1.(*decoder).document(0xc042091898, 0xc04203e660, 0x7d9620, 0xc0420c20f0, 0x199, 0xc042091848)
        C:/Go/work/src/gopkg.in/yaml.v1/decode.go:273 +0x8b
gopkg.in/yaml%2ev1.(*decoder).unmarshal(0xc042091898, 0xc04203e660, 0x7d9620, 0xc0420c20f0, 0x199, 0x199)
        C:/Go/work/src/gopkg.in/yaml.v1/decode.go:255 +0x152
gopkg.in/yaml%2ev1.Unmarshal(0xc042080d80, 0x23, 0x223, 0x7ab180, 0xc0420c20f0, 0x0, 0x0)
        C:/Go/work/src/gopkg.in/yaml.v1/yaml.go:95 +0x1da
github.com/goreleaser/releaser/config.Load(0xc0420053b0, 0xe, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        C:/Go/work/src/github.com/goreleaser/releaser/config/config.go:54 +0xf2
main.main.func1(0xc042040640, 0xc042040640, 0xc042091c27)
        C:/Go/work/src/github.com/goreleaser/releaser/main.go:39 +0x77
github.com/urfave/cli.HandleAction(0x77e500, 0x831440, 0xc042040640, 0xc04203e4e0, 0x0)
        C:/Go/work/src/github.com/urfave/cli/app.go:485 +0xdb
github.com/urfave/cli.(*App).Run(0xc042070d00, 0xc042007fb0, 0x3, 0x3, 0x0, 0x0)
        C:/Go/work/src/github.com/urfave/cli/app.go:259 +0x756
main.main()
        C:/Go/work/src/github.com/goreleaser/releaser/main.go:52 +0x1e4

We are using config as context

The ProjectConfig is actually a mix of the config a "context", maybe we should refactor it...

Add `conflicts_with` brew section

That may be useful for some people.

get/latest could be better

We can put https://github.com/goreleaser/get/blob/master/latest as a asset on our jekyll site, so the url become cleaner, e.g.: http://goreleaser.github.io/get (instead of https://raw.githubusercontent.com/goreleaser/get/master/latest)

Just to say: Big Thx!

Just to say: Big Thx!

Homebrew formulae improvements

The homebrew tap is a little hacky to support linuxbrew (getting os from uname).

I was thinking:

• is linuxbrew support really required?
• is anyone still using i386 macs?

Maybe we could simplify it by just using the Darwin_x86_64 build directly.

Support for Homebrew formula in subdirectories

As mentioned here it's possible (and suggested) to keep formulas of a tap in a subdirectory.
Either there could be a new option to specify the dir to write to, or even simpler would be to add it to the current repo option:

To save it on the top level (as currently supported) nothing would change:

brew:
  repo: user/homebrew-tap

To use the Formula subdirectory instead you would do:

brew:
  repo: user/homebrew-tap/Formula

Am I missing any cases where this might conflict?

building Desktop installers

I was wondering if you would take a PR for building Desktop installers ?

The main golang build pipeline has code in it to make proper installers for Windows and OSX and Linux- Not all the code they use is needed, but some of it is.
Travis is the perfect place to do these types of builds too, because to build these final installers requires being on the actual OS.

Document GITHUB_TOKEN

replace oses and arches by goos and goarch?

Seems more brainless... oses and arches may be confusing...

add support for custom env variables during build

is this a needed feature?

Add lowercase versions to default files

https://github.com/goreleaser/releaser/blob/master/config/config.go#L14

I know it's more common to have readme and license files with uppercase, but there are also projects out there using the lowercase versions.
I guess adding them wouldn't be a big deal and might come in handy for a few people.
What do you think @caarlos0?

add caveats?

add CHANGELOG* to patterns of files to add

Consider using zip for windows builds

Currently releaser builds archives for all 3 destinations as tar.gz, windows doesn't support opening these archives out-of-the-box and requires 7-zip to be installed, which to normal users might be troublesome, consider adding option to archive files for windows as zip.

Make more configuration optional

I also like the idea of a quick way to create a default config file (#47), but many projects probably have the same configuration and wouldn't even need any configuration file if the defaults are set right.

• I think in most cases the repo option could be parse from the git remote.

• Also, many Go binaries follow the convention of naming the binary like the directory containing the main.go file. This could be used as binary_name.

Would it be useful to make those two settings optional?

Am I doing this wrong?

So I decided to free up some time and built a small experiment repo where I tried to build a minimal docker image with travis but now I also wanted to add a release for tags, problem is it just won't build, I used the snippet provided in readme, here's a link to travis build log.

remove pkg/errors usage (wrong import)

improve release changelog

Ideas:

• get merged PR titles and link them instead of the commit
• lone commits (which were not merged within a PR) can be linked as it is today

deal with existing releases

If the user creates the release via the github web interface, goreleaser will fail trying to create it.

Maybe it's worth fixing...

improve main.go

windows support?

Mention that releasing uses Git tags

... and that GoReleaser expects a tag to exist.

create packages with fpm

See: https://www.reddit.com/r/golang/comments/5l3i9b/deliver_go_binaries_as_fast_and_easy_as_possible/dbsrx16/

Updating documentation after using "go get" in docs

The introduction states that no packages is required for using GoRelesaser,

GoReleaser is built for CI tools, you only need a single command line in your build script. Therefore, no package is required

Maybe this should be updated to convey with the use of go get:

after_success:
  test -n "$TRAVIS_TAG" && go get github.com/goreleaser/goreleaser && goreleaser

rename goreleaser/homebrew-formulae to goreleaser/homebrew-tap

It just reads better (IMHO):

brew install goreleaser/tap/release

Also change readme to comply with this rename.

send metrics somewhere?

just to know how many people are actually using it 👍

document main.go version with ldflags usage

Custom naming archive

I would like to be able to name the final archive myself, maybe use text/template ? For example I want to name the archive counter-test-v0.2.2-Windows_x86_64.tar.gz, currently I would have to generate the config using a template myself, it would be nice if it was to do that with config itself.

Change `binary_name` to `binary`

Wouldn't this still be descriptive enough, especially since it is in the build sub-section of the configuration file now?

any idea about add dependencies of the brew Formula

What about

brew:
  repo: user/homebrew-tap
  folder: Formula
  dependencies:
    - pillow
    - other...

GithubRelease failed: POST https://api.github.com/repos/.../releases: 401 Bad credentials []

How do you let releaser use the Github credentials?

Create initial release?

Hi,

not sure if I got this wrong, but the first "curl -s https://raw.githubusercontent.com/goreleaser/get/master/latest | bash" only works for me when there´s already two tags with at least one commit diff present. The error is "exit status 128: fatal: Not a valid object name v1^" when there´s only one tag present.

What I want to achieve is

1. create new repo
2. create first release (e.g. only 1 commit, 1 tag)
3. call goreleaser

Is this by design, am I doing something wrong or is this a bug?

Thx for your efforts. I like the tool.

Update docs on how to avoid deploying multiple times

When running Travis CI I like to test multiple OSes and maybe even different Go version.
However, only one of them should deploy the binaries.
My current solution is a test like this:
https://github.com/qvl/sleepto/blob/master/.travis.yml#L9

I don't know if we should mention this in the docs.

Also, what I don't like about this solution is, that it deploys as soon as this particular CI run was successful. As far as I know there is no way of running code only after all OS-version combination have been completed?

Consistent project name

Is it releaser, release, Goreleaser, goreleaser, GoReleaser,... ?

Also, the released binary is called release and the binary I get via go get is called releaser.
(Personally, I would prefer a goreleaser binary)

What do you think?

allow ldflags customization?