On Tue, Aug 11, 2020 at 7:48 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > On 8/11/20 4:45 AM, Ondrej Mosnacek wrote: > > > This patch removes the old hackery to test-build the testsuite and > > replaces it with scripts that run the full testsuite on a Fedora VM. The > > scripts are based on William Roberts' work on SELinux userspace CI [1], > > which does a similar thing. > > > > This patch enables testing on Fedora 32 (the image ships with kernel > > 5.6.6) and Rawhide nightly images (with kernels close to mainline). > > Switching to other versions can be controlled via CI environment > > variables. > > > > One downside is that with this patch we lose the test build against > > refpolicy, but it shouldn't be too hard to add testing on a Debian VM > > with refpolicy later on. > > > > [1] https://github.com/SELinuxProject/selinux/commit/562d6d15272420542bf65da328bc5300219fce76 > > > > Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx> > > --- > > Thanks, this is great. One more question: when we added the VM-based > testing to the selinux userspace travis, we nonetheless kept the old > limited build / unit test run on the Ubuntu image as well to provide > some degree of sanity checking there (plus it is much faster and > possibly less prone to intermittent breakage). Is there a reason to > drop the "old hackery" entirely or should we retain it too? Up to you. The problem with the existing CI is that it broke recently :) I realize now, that probably no one knows but me (I noticed it when preparing to merge Richard's SCTP patch), so I should have explained that better in the commit message... Basically all my attempts at fixing it quickly and nicely have failed, so I figured it would be easier to try to adopt the KVM approach instead. I see your point about the existing CI being faster (well, at least when there is a cache snapshot available...), but unfortunately the testsuite logic is too much dependent on the kernel version and the uapi headers that it's not easy to keep it working in the Travis environment... Add to it the complexity of selinuxfs mocking, building and installing two policy variants... It was good while it lasted, but I think it's time for it to retire now. -- Ondrej Mosnacek Software Engineer, Platform Security - SELinux kernel Red Hat, Inc.
