Docker-based packaging workflow in GitHub Actions.

[Ferroin]

Summary

This implements a new Docker-based packaging CI workflow in GitHub Actions. It still uses the same trigger commits as the existing LXC-based workflow we have in Travis so that minimal changes are needed to have it work correctly.

This requires the addition of two secrets to the repository itself:

• PACKAGE_CLOUD_REPO: This specifies which PackageCloud repository to push the packages to.
• PACKAGE_CLOUD_API_KEY: This specifies the PackageCloud API key to use when uploading packages.

This leverages GitHub Actions' matrix build feature to keep overall code in the workflow file to a minimum.

Component Name

area/ci
area/packaging

Additional Information

Fixes: #7346
Fixes: #7822

[Ferroin]

OK, this is finally ready for a round of preliminary review. It still is not quite ready to be merged (we still need more testing of the upload handling, as well as needing to move the repo cleanup process from Travis to GHA), but the code that is here is unlikely to change significantly unless we run into serious complications.

[Ferroin]

For those who want to verify the packages that would be produced by this locally, here are the steps required to use the same package building process locally:

1. Pull the correct Docker image for your distribution and architecture from the netdata/package-builders repository on Docker Hub. There is one tag there for each supported distribution.
2. From your local copy of the Netdata sources, run: docker run -it --rm -v $PWD:/netdata netdata/package-builders:<tag>, replacing <tag> with the tag for your distribution (for example debian10 for a Debian 10 package).

This will create an artifacts directory in the Netdata source tree on the host system which will contain the package files, which you can then manually install on your system by passing them directly to your package manager. The generated packages will list a version of 0.1 instead of the current version, but are otherwise the current version of the code provided by the Netdata sources used for the build.

The package building process itself takes about 5-10 minutes on a reasonably fast system.

Note that we currently only build for 64-bit x86 on most of these platforms (and the handful we don’t only include 32-bit x86 beyond that).

[netdata-community-bot]

This pull request has been mentioned on Netdata Community. There might be relevant details there:

https://community.netdata.cloud/t/centos-8-rpms-missing-from-cloudpackage/1077/2