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

Create Multiple Archives #705

Open
tdmanv opened this Issue Jun 27, 2018 · 13 comments

Comments

Projects
None yet
4 participants
@tdmanv
Copy link

tdmanv commented Jun 27, 2018

Is your feature request related to a problem? Please describe.
We would like to release a server/client from a single repo using goreleaser.

Describe the solution you'd like
Ideally we'd be able to create multiple archives - one for the server and one for the client. When installing the client, it shouldn't be required to get the server binary as well. We should also be able to limit the number of os/arch for client/server independently.

Describe alternatives you've considered
We're currently using multiple builds and the client and server get packaged in every archive.

@stale

This comment has been minimized.

Copy link

stale bot commented Aug 27, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Aug 27, 2018

@bep

This comment has been minimized.

Copy link
Contributor

bep commented Aug 30, 2018

Hugo really needs this ... I'm in semi-manual build mode at the moment, and that is a pain when we're doing a fair amount of releases.

@stale stale bot removed the wontfix label Aug 30, 2018

@caarlos0

This comment has been minimized.

Copy link
Member

caarlos0 commented Aug 31, 2018

I was thinking in doing something similar to the docker image:

archives:
  - binaries: [] # empty means all
    format: zip
    name_template: full
  - binaries: ['foo']
    name_template: foo
  - binaries: ['bar']
    name_template: bar

what do you folks think?

@bep

This comment has been minimized.

Copy link
Contributor

bep commented Aug 31, 2018

what do you folks think?

Not sure. In the "Hugo use case", we have a set of builds producing hugo (name of binary), which should be packaged in different archives.

{{.ProjectName}}_{{.Version}}_{{.Os}}-{{.Arch}}

The above is is the current archive name template. The above works because we have 2 goreleaser config: One with project_name hugo, one with hugo_extended.

The creator of this issue has probably a simpler requirement that fits your outline better, e.g. binaries myapp-server and myapp-client.

But I think that in the Go world where plugins are hard, I think having a way to package different bundles of the same app would be really useful for many. And you would want these to be named the same so they could be "drop-in-replacements".

@caarlos0

This comment has been minimized.

Copy link
Member

caarlos0 commented Aug 31, 2018

@bep hmm

so, yeah, my example maybe wasn't good, in hugo use case it would look like:

archives:
  - binaries: ['hugo']
    name_template: 'hugo_{{.Version}}_{{.Os}}-{{.Arch}}'
  - binaries: ['hugo_extended']
    name_template: 'hugo_extended_{{.Version}}_{{.Os}}-{{.Arch}}'

so, in the end you'll have the hugo archives and the hugo_extended archives for each build...

@bep

This comment has been minimized.

Copy link
Contributor

bep commented Aug 31, 2018

Ah, OK, then I misunderstood. Yea, that looks good.

@tdmanv

This comment has been minimized.

Copy link
Author

tdmanv commented Aug 31, 2018

That also works for our use case. Thanks!

@caarlos0

This comment has been minimized.

Copy link
Member

caarlos0 commented Sep 3, 2018

this is bigger than previously anticipated: brew, scoop and http pipes will also need to change in order to support this.

@caarlos0 caarlos0 referenced this issue Sep 3, 2018

Closed

wip: feat: multiple archives #787

3 of 8 tasks complete
@caarlos0

This comment has been minimized.

Copy link
Member

caarlos0 commented Sep 3, 2018

check the WIP on #787

@stale

This comment has been minimized.

Copy link

stale bot commented Oct 31, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@caarlos0

This comment has been minimized.

Copy link
Member

caarlos0 commented Jan 1, 2019

So, I've been thinking about this, and I think we can split it in several steps:

  • scoop pipe doesn't even support multiple builds yet, this need to be fix so it can support multiple archives too
  • same thing with brew pipe
  • in the config, we need to be able to reference a build in an archive config
  • in the config, we need to be able to reference an archive in different pipes (and reference the build from which the binary came from)
  • in the artifacts, we should be able to reference the origin artifacts/configs

From here we have 2 possible strategies:

1. add multiple support to everything else first, and then multiple archives
  • add multiple brew support
  • add multiple scoop support
  • add multiple snap support
  • add multiple http/artifactory support
  • add multiple archives
2. add multiple archive first, and then everything else
  • add multiple archives (with everything else using archives[0])
  • add multiple brew support
  • add multiple scoop support
  • add multiple snap support
  • add multiple http/artifactory support

My idea would be to start implementing this and releasing small pieces of it until we get everything done.

@frapposelli

This comment has been minimized.

Copy link

frapposelli commented Feb 7, 2019

this looks like a sizable change, any chance that this can be implemented with a feature flag? I'm sure there are people (like me 😅) that are interested only in a subset of these features.

@caarlos0

This comment has been minimized.

Copy link
Member

caarlos0 commented Feb 7, 2019

problem is that goreleaser was designed on the premise of a single archive, so there are a lot of places where that is very coupled... I'm reluctant to even work on this because I can break several things, unfortunately.... but I will! One of those rainy saturdays I'll get to it and get it done haha

Meanwhile, there is a WIP on #942 and some feedback would be lovely! I'm not sure, for example, in what's a good way to reference an archive inside another pipe (eg. brew).
Right now, my idea was to add a id field to each archive, so the user can:

archives:
- id: archive1
  # etc..
brews:
- id: brew1
  archives:
  - archive1
  - archive2
 # etc

but it seems confusing... I was even thinking about migrating the config to HCL because of that (terraform does it very well IMO).

Anyway, not sure how this will work yet :/

@kskewes kskewes referenced this issue Feb 8, 2019

Open

[WIP] GoReleaser #140

1 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment