Move CI process to GitHub Actions and add CD pipelines

[mxschmitt]

Hello,

as discussed over Twitter: https://twitter.com/mholt6/status/1203790630880600065 my idea would be to introduce GoReleaser into the project. Currently as far as I've seen for CI is Azure Pipelines in use. In this issue I would:

• Migrate to GitHub Actions, so CI functionality is moved fully to GitHub Actions (so everything is at a central place)
• Add CD functionality with GoReleaser over GitHub Actions to automatically attach the binaries for the different architectures to the GitHub Release once a new Tag was published.
• Configure GoReleaser that way, that deb packages were created. We have to discuss also where we want to publish / release them

Initial goal: Provide deb/rem packages to the end users, so apt install caddy is possible.

root@eea4381d15b1:/# apt install caddy
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package caddy

cc @caarlos0 (Creator of GoReleaser)

[carlwgeorge]

Uploading packages to GitHub releases won't make apt install caddy work. Someone has to put in the work to get packages into the distro repositories. This means following the distro packaging guidelines and using the distro build systems. You can't just hand a built package to a distro and ask them to ship it. This work has already been done for Fedora, we're just lacking the same on Debian (which will also filter in to Ubuntu). Goreleaser may be desirable for other reasons, but it won't be for the packages.

[tobya]

@mxschmitt Great. I would be brilliant to have binaries of each release / github commit.

I'm happy to try to help if needed.

[mxschmitt]

Sure the deb packages are not publishing from themselves, there is a strict process behind. But currently it stuck, that the actual deb/rem packages are created, so once this is done we can start the actual publish process.

I would start with several iterations / PRs:

• Move from Azure Pipelines to GitHub Actions
• Add CD functionality to it, so the binaries for the different architectures will be automatically attached if a Tag was created
• Also attach the deb/rem packages
• Publish the actual packages to the different repos

[caarlos0]

If you want to ship the packages to official distro repos, yes, goreleaser wont help much for that particularly.

You could upload to a 3rd party repo, like packagecloud for example, in which case goreleaser can do it automatically.

[mholt]

@francislavoie Now that we've switched to GitHub Actions, next step -- at some point -- is to make releases at new tags, at least on the GitHub Releases page, if possible! I think that'd be pretty helpful. Right now v2 releases take about an hour or two to get right, and it's kinda tedious.

[mholt]

For note, a few changes we want to make:

• Use caching to speed up builds (Use matrix includes to set per-os variables, simplify cross-platform #3166 (comment))
• Build artifacts with proper versioning and better name on Linux if possible (Use matrix includes to set per-os variables, simplify cross-platform #3166 (comment))

[francislavoie]

Verdict is caching is not much better #3167

[francislavoie]

Cleaned up build artifact filenames #3168

Only remaining task is to add version info to the binaries, which we should be able to do with https://github.com/caddyserver/builder soon.

Then probably using GoReleaser, which @mohammed90 is working on AFAIK

[lskillen]

You could also consider @cloudsmith-io for the packages hosting, to get the apt install method working. If you need any assistance with it, just let me know! :)

[francislavoie]

This is done! #3152 switched the project to using Github Actions for CI, and https://github.com/caddyserver/caddy/releases/tag/v2.0.0-rc.1 was the first release to use GoReleaser!