Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unexpected behavior in archive:files: section -- how to specify no additional files #602

client9 opened this issue Mar 9, 2018 · 7 comments


Copy link

@client9 client9 commented Mar 9, 2018


  • Are you running the latest version? HEAD
  • Did you perform a search to see if this problem was already reported?

For more information, see the CONTRIBUTING guide.


It's not clear how to specify no additional files to be included in the archive. Bug? Doc Bug? Feature?


$go version
go version go1.10 darwin/amd64

$ uname -a
Darwin nickg-macbook 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64

Steps to Reproduce

i wanted "classic goreleaser" behavior where the tar.gz contained just the binary. Currently, it tries to add license, readme and changelog info.

In the archive stanza, in the files section, I tried

  • empty. That just used the default behavior, and not no additional files -- expected no additional files, but I get it... sorta a yaml limitation
  • "none" (an non-existent file) That broke the build saying it couldn't find the file - definitely not expected, but I guess I get it
  • "none*" -- that worked. Weird.
  name_template: "{{ .Binary }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}"
    amd64: 64bit
    386: 32bit
    darwin: mac
    - none*

you can screw around in

git clone
cd misspell

This could be just a documentation bug.

Copy link

@caarlos0 caarlos0 commented Mar 9, 2018

hmm, I think this never worked this way, if it did, it was a bug before...

the problem is that the default is set to license and etc, so if you leave it empty it will add those files anyway.

adding the none* works because goreleaser globs it, and since there are no files matching that glob, it works.

not sure what is the right thing to do here...

Copy link
Contributor Author

@client9 client9 commented Mar 9, 2018

ha! you are right. It always worked that way. I just checked some old packages I made using goreleaser. I never noticed!

might just be a documentation bug... or maybe?? if you put the binary name only in the files section then, that's a special case.


means "just the binary" ? Maybe that is less gross than "none*"

really not a big deal either way. I can live with "none*"

Copy link

@caarlos0 caarlos0 commented Mar 10, 2018

yeah, I'm not sure as well... looking at the sources, there is not a good retro-compatible way of adding that...

I think none* is the better hack atm :/

caarlos0 added a commit that referenced this issue Mar 10, 2018
dunno, probably was drunk at the time

refs #602
@caarlos0 caarlos0 added the docs label Mar 12, 2018
@caarlos0 caarlos0 self-assigned this Mar 12, 2018
@caarlos0 caarlos0 added this to the v1.0.0 milestone Mar 12, 2018
Copy link

@caarlos0 caarlos0 commented Mar 12, 2018

I'll just point that hack down on the docs...

@caarlos0 caarlos0 closed this in 7648760 Mar 12, 2018
george-angel added a commit to uw-labs/strongbox that referenced this issue Mar 12, 2018
More information here:
Copy link

@Ilyes512 Ilyes512 commented Nov 11, 2018

Is there a reason you choose to use a glob instead of a non glob like:

  - none
Copy link

@caarlos0 caarlos0 commented Nov 11, 2018

Yes, if you choose a glob that doesn’t match any files, z-glob (lib uses for globs) returns am empty list. If you pass a non-glob and the file doesn’t exist, it returns a file not found kind of error...

If recall correctly, that’s it 🤔

Copy link

@github-actions github-actions bot commented Nov 19, 2020

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants