add github actions CI workflow

[rgl]

This adds an CI workflow that builds the debian package in a Ubuntu 18.04 CI node.

You can see this in action at https://github.com/rgl/lms/actions.

I've installed the .deb package (available to download at the workflow home page Artifacts link) in a Ubuntu 20.04 machine, and I was able to use MeshCommander to gracefully shutdown the OS/machine :-)

I have one doubt, that machine is running Ubuntu Server, that by default, does not include/needs dbus, and a such, understandingly, the lms service complains that it cannot access dbus (but seems to work fine despite that error) with:

ago 18 20:19:05 vagrant LMS[1368]: Intel(R) Management Engine (Intel(R) ME) error(s) occurred. Please review Intel(R) ME logs.
ago 18 20:19:05 vagrant lms_svc[1368]: (140316236904192)[2020-08-18 20:19:05.653145][LM_ERROR   ]  Failed to get KVM status
ago 18 20:19:05 vagrant lms_svc[1368]: (140315837970176)[2020-08-18 20:19:05.662782][LM_ERROR   ]  AdapterListInfo Failed to get Devices property: The name org.freedesktop.Net
ago 18 20:19:07 vagrant lms_svc[1368]: (140316236904192)[2020-08-18 20:19:07.848263][LM_ERROR   ]  StatusEventHandler: GetAMTEthernetPortSettings failed

Is there a way to build lms with all the supported backends (dbus, network manager, etc) and let the administrator choose which ones to use? that is, move that decision to runtime instead of build time? does it make sense to have this build option?

I'm asking because, like it is, is going to be a hard to package this software; or we have to build different packages for each of the options combinations (e.g. lms-dbus.deb, lms-nm.deb, etc).

[ausyskin]

Are you sure that you don't have DBus on you server? The graceful shutdown uses "ScheduleShutdown" from "org.freedesktop.login1.Manager".
Seems that you don't have NM there, so some features of the LMS will not work. I've failed to find a way to obtain list of domains associated with particular network adapter without high-level managers, like NM or ConnMan.

[rgl]

@ausyskin, I was finally be able to pick this up again.

You are correct, Debian 11 server actually has dbus running. Thanks for questioning that :-)

I do not use NM nor CM. I'll be using the netlink flavor of lms. It would be nice to have a comparison list of features between those three documented in the readme.

I've redid the PR to use docker to build the binaries for debian 11 and ubuntu 20.04. Because those two distributions use different dependencies versions, and that makes the .deb file incompatible between them.

I'm not sure what to do with the NETWORK_NM and NETWORK_CM build arguments, so they can be set as a docker build argument (they are currently both OFF, but only because that fits my own local usage). Since these are build time settings (as opposed to runtime), maybe this should generate three different packages instead (1. using netlink; 2. using NM; 3. using CM)?

You can see the example GitHub Actions produced Artifacts at https://github.com/rgl/lms/actions. The .deb files will end up with a different name, depending on the distribution (e.g. lms-2151.0.0-debian-11.deb); this filename is also up for discussion.

Let me known what you think and how to proceed from here.

[rgl]

I've updated this PR to also generate the Ubuntu 22.04 deb package.

I've documented how this can be installed in https://github.com/rgl/lms-binaries.

There is a problem with the packages, they do not include their dependencies. This means, its awkward to install the lms package, because the user/admin must somehow known what dependencies he has to install.

Is not having the .deb package have a Depends field expected?

[rgl]

I think they are limited by default to 90 days, but I'm good with any retention period.

My main goal with this action is to ensure that any code change can still build the code and generate the package for Debian/Ubuntu.