RFC: GoReleaser files

[caarlos0]

GoReleaser has good defaults regarding which files to add to the release when it is only its own products (the binaries, archives, etc).

Of course, many projects will need to add more files than just the binaries.

Over the years, we added more and more things, and the current state is now a bit weird IMHO.

We have:

• ids (to filter by source id)
• extra_files
• templated_extra_files
• just files
• inability to add other produced types to some parts of the configuration (e.g. archives instead of binaries, shared libraries, etc)

I propose a fix for this, introducing, "just files"™️:

nfpms:
- files:
  - kind: binary
    dst: /usr/bin
  - kind: c-shared
    dst: /usr/lib
    ids: [foo, bar]
  - src: ./README.md
    dst: /usr/share/pkg
  - src: ./LICENSE
    dst: /usr/share/pkg
    templated: true

This would, in the example of nFPMs, replace the meta, bindir, ids, extra_files and templated_extra_files.

We can probably make it backwards compatible, deprecate the old options, and remove them on v2.

I think it should replace all previous, and add support for things that weren't clear before.

The only downside is that if you just want to add a new file to the extra_files section, you'll need to add the binary as well - this could be mitigated by adding better defaults to the jsonschema, as well as handling it on goreleaser init. Maybe, we even drop the defaults at runtime for this particular thing, as then its less confusing.

I'm open to hear your thoughts on this.

Thank you!

[ryancurrah]

This looks like a natural way to specify files to be included in a package. I like how you could potentially include multiple builds in a single package. For Docker why is a build ID required, feels like v2 could be a good opportunity to decouple that requirement.

[caarlos0]

yes!

so, the idea is to use this same interface for docker, packaging, archives, etc... so they all look the same instead of having to guess the different syntaxes.

the only thing that docker would have to be a bit different at is that the dst would not be the destination inside the built image, but inside the temporary folder used as context for building the image.

[ryancurrah]

Ok. I was thinking of extra_files when building Docker images, would be cool if we did not need a build ID, that would potentially allow to build Docker image thats related but not needing a build installed on it.

[caarlos0]

yes, my proposal would allow that too, something like this:

dockers:
- files:
  - src: ./foo.txt
    dst: ./bar.txt

FROM whatever
ADD bar.txt /var/lib/bar
# ...

[caarlos0]

see #4396, #4346, #2650, #4423

all problems that would be solved/easier to reason about in terms of this proposal IMHO

[caarlos0]

another thing we should handle in this one: options

E.g., for the blob uploader, we might need to set some headers.

One option is to have the headers global per configuration, and another per file... both may cause code to be repeated in different cases, so I guess its a matter of which one might happen more...

[jacob121532]