Add packages to release

[SuperQ]

• Add deb/rpm packages to goreleaser.

Signed-off-by: Ben Kochie superq@gmail.com

[ldez]

Hello,

Sorry but it's a bit more complex than just add the goreleaser configuration:

1. it's not possible to change the checksum file name, because some other elements already use this file
2. NFPM is required to be able to build .deb or .rpm

From my memory, lego is already available from Debian repositories, and maybe on rpm repositories.

I prefer to not manage those packaging because this kind of build can be difficult to maintain.

Thank you anyway.

[SuperQ]

Ahh, I added the checksums thing because I think in previous versions of goreleaser, the checksums file was missing by default. This appears to not be the case anymore. I have removed this change.

NFPM is built into goreleaser as a library. No changes to the build pipeline are required.

Lego is technicaly available in Debian, but as usual, it does not get upated in stable. So the only available version is 0.3.1.

[dmke]

I wonder if providing deb or rpm packages (i.e. without a proper repository infrastructure) is such a good idea. One of the benefit expected by users of those package formats, and not provided by Github, is an actual package repository, for automatic/semi-automatic updates.

So, after downloading and installing a hypothetical .deb file from our release page, the users need to:

1. recognize new releases (Github notifications may help),
2. go to the download page and download the latest release (this is a mostly manual process, but the Github API may help), and
3. install the released file (i.e. run a command like dpkg -i lego.deb).

Comparing to the .tar.gz files we already provide, the workflow is the same, just replace the last step with tar -xf lego.tar.gz -C /usr/bin lego.

That being said, I'm not against providing deb/rpm packages, per se; especially if it really doesn't affect the build/release pipeline. The wording on the GoReleaser docs is a bit weird: "GoReleaser can be wired to nfpm" can be interpreted as "have nfpm in $PATH, and we'll produce packages", but their go.mod actually includes nfpm.

In the end, @ldez creates the releases, so I'm in 100% support of his decision.

[ldez]

I forgot to mention another point: the build time in Travis is limited to 50 min.

Currently, a release takes about 45 minutes, we don't have much margin.

https://travis-ci.com/github/go-acme/lego/builds/199000810
https://travis-ci.com/github/go-acme/lego/builds/182605915

[dmke]

Hm. This is a bit off-topic, but given the recent announcement (1000 min/month for their free/trial plan), maybe we should look into Github Actions?

[SuperQ]

For providing proper repo, this can be done with PackageCloud. They offer free accounts to open source projects.

We (Prometheus project) are quite happy with CircleCI.

[jhg03a]

Now that the project has transitioned to Github Actions, can we merge this to start getting official deb/rpm?

[jhg03a]

PackageCloud sounds pretty awesome if the grant is possible to make them more accessible, but that's a separate PR.