goreleaser / goreleaser Goto Github PK
View Code? Open in Web Editor NEWDeliver Go binaries as fast and easily as possible
Home Page: https://goreleaser.com
License: MIT License
Deliver Go binaries as fast and easily as possible
Home Page: https://goreleaser.com
License: MIT License
That may be useful for some people.
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:
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
)
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
maybe it is a cool feature to add...
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.
Ideas:
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...
Wouldn't this still be descriptive enough, especially since it is in the build
sub-section of the configuration file now?
The ProjectConfig
is actually a mix of the config a "context", maybe we should refactor it...
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?
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.
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?
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?
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?
is this a needed feature?
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 =)
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
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
The homebrew tap is a little hacky to support linuxbrew (getting os from uname).
I was thinking:
Maybe we could simplify it by just using the Darwin_x86_64
build directly.
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?
What about
brew:
repo: user/homebrew-tap
folder: Formula
dependencies:
- pillow
- other...
How do you let releaser use the Github credentials?
It just reads better (IMHO):
brew install goreleaser/tap/release
Also change readme to comply with this rename.
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?
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.
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.
armel
for softfloat (compatible with ARMv5) or armhf
for hardware floating point (ARMv6 and above).See https://golang.org/doc/install/source#environment
All ARMv8-A processors.
"Big-endian 64-bit PowerPC (linux/ppc64) only requires the POWER5 architecture." (from
https://golang.org/doc/go1.7#ports)
"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)
MIPS III or higher. Builder is using MIPS64r2.
MIPS III or higher in little endian mode. Builders are using Loongson 2E/2F.
z196+
MIPS32r1, with FPU or kernel FPU emulation
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
just to know how many people are actually using it 👍
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.
Just to say: Big Thx!
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
... and that GoReleaser expects a tag to exist.
If the user creates the release via the github web interface, goreleaser will fail trying to create it.
Maybe it's worth fixing...
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?
Seems more brainless... oses and arches may be confusing...
as described in #13 (comment) and #13 (comment)
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.
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.
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
Is this by design, am I doing something wrong or is this a bug?
Thx for your efforts. I like the tool.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.