Add automated builds to speed adoption of latest kernel security fixes?

[romanows]

Any chance you could add a "nightly" release channel for the LIS RPMs? It looks like the LIS codebase will get an update to support later kernel versions long before a downloadable release of the fix is available.

For example, it looks like support for the latest CentOS 7.6 kernel as of today (3.10.0-957.27.2.el7.x86_64) has been present for over three weeks in the lis-rpm-build-pipeline repo. However, it is not present in the only artifact available for download (e.g., the 4.3.3 download from https://aka.ms/lis).

I know this is a pain to setup; thanks for considering it.

[romanows]

Okay, digging into this, there is some interesting stuff going on. Docs and a bit more verbose error logging would make this better. Here's what I'm finding:

The "latestsupportedkernel" file is part of a backup method of determining compatibility. When a user runs ./upgrade.sh, it will not get used if the more complicated method of determining compatibility succeeds. And it succeeds for the latest kernel right now.

One interesting issue is that the fallback method will fail if used and the user might be left thinking that the current kernel is unsupported. For example, if you run ./upgrade as a normal user, no sudo, then the primary compatibility detection method fails and the fallback method is used, and reports that the kernel is not compatible!

A good way to fix this would be to add some docs and tweak some of the logging methods-- notably echoing when the "primary compatibility check" fails and that the "fallback compatibility check could not determine that the kernel is compatible with this release of LIS". Or language to that effect. It'd probably be worth renaming latestsupportedkernel to something that indicates it is isn't actually used in the happy path, maybe something like latestsupportedkernelfallback or something like that.

Given all of this, if you feel that you are reasonable quick at releasing new LIS versions when needed, then there's no need to expose nightly builds and this issue can be closed. Thanks.