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.
