On Thu, May 14, 2020 at 5:31 PM William Roberts <bill.c.roberts@xxxxxxxxx> wrote: > > On Thu, May 14, 2020 at 5:21 PM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > On Thu, May 14, 2020 at 5:03 PM William Roberts > > <bill.c.roberts@xxxxxxxxx> wrote: > > > > > > I just wanted to lay out a demo of a Fedora 32 cloud VM image booting > > > on Travis with execution happening in the Fedora VM. > > > The Fedora VM contains the selinux source code for that particular > > > travis build, so it has the PR patches, etc. > > > The VM has networking. > > > > > > The build logs for the Travis run are here: > > > - https://travis-ci.org/github/williamcroberts/selinux/builds/687185489 > > > > > > Which comes from my git tree here: > > > - https://github.com/williamcroberts/selinux/tree/kvm-fedora-testing > > > > > > Note that it's super messy, I need to go through and cleanup both the > > > patch and the git > > > history. I also should verify the downloaded image is signed for the VM. > > > Also note that I may rebase/squash my git branch at any time. > > > > > > Petr started a release document here: > > > - https://github.com/bachradsusi/SELinuxProject-selinux/blob/RELEASE/RELEASE_PROCESS.md > > > > > > I'd like to gather feedback, and perhaps more comments on: > > > 1. Is this CI approach worth continuing? > > > 2. Comments on the CI scripts (I have no idea what I am doing, common issue) > > > 3. Comments, patches, suggestions on what tests to run in this CI environment. > > > 4. More information in in the RELEASE_PROCESS.md file. I made some > > > comments there > > > as well on ideas. > > > > > > My goal here is that a release can occur if CI is passing without > > > worry, and that > > > we automate manual steps as much as possible. This way, if we get hit by a bus > > > releases can occur without much effort. > > > > I'm amazed travis-ci supports all of that (especially for free). > > Hopefully you aren't violating their terms of use. > > Not that I am aware of and I read their terms of use. > https://docs.travis-ci.com/legal/terms-of-service/ > > They don't seem to limit what you can do, it seems to be centered > around availability, liability and support. > > I stumbled into other projects on github that were running virsh commands > > > The biggest thing I'd add is to build and install the selinux > > userspace in place of the stock Fedora versions (sudo make > > LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install install-pywrap relabel) and > > then build and run the selinux-testsuite to exercise the SELinux > > userspace and kernel runtime functionality. Other things to possibly > > Perfect, that's the info I was looking for. > > > add would be rebuilding upstream refpolicy (similar to its > > .travis.yml) with the latest userspace, rebuilding and running setools > > (but until we decouple it from libsepol internals this will > > periodically break). > > If it breaks, it breaks, just means we need to merge something or actually > fix it properly IIUC. So I just wanted to share, that the test suite is running with a PASS on a travis CI instance with a nested KVM of Fedora32. https://travis-ci.org/github/williamcroberts/selinux/builds/687592735 Next week I'll clean this up and make sure that its working consistently. I've had 2 hangs when building the libselinux src, not sure why.. I don't want a CI check that'd flaky, so I want to do some more testing. An example is on this build: https://travis-ci.org/github/williamcroberts/selinux/builds/687496735 I'm gonna assume I need to allocate more memory and im gonna bump the vcpu count as well to match the host. As Travis gives us two cores. Bill
