On Thu, May 14, 2020 at 11:00 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. Hi, This sounds like a nice idea :) Also it appears it only takes 5 minutes to run the whole Travis CI job of setting the Fedora VM up and booting it, which is more than acceptable in term of delays (and is very quicker than building and testing the project itself). This could allow to run more tests that require to be able to manage the SELinux policy, automatically at every pull requests. By the way I wasn't expecting Travis-CI to easily allow nested virtualization ("nested" because jobs are already run inside VMs, IIRC). If it works, it is great! Some quick thoughts/suggestions/comments that I have in my head after reading very quickly your changes: - The networking setup of the VM seems to be more complex than needed because you are relying on getting the IP address from DHCP. Would it be possible to configure libvirt with port forwarding, so that "ssh -p 2222 127.0.0.1" always work? (with raw QEMU, the command-line parameters would be something like -net nic,model=virtio,macaddr=52:54:00:12:34:56 -net user,hostfwd=tcp:127.0.0.1:2222-:22) - Usually the helper scripts are located in directory scripts/, which make them more easily discovered by people reading the code (hidden files and directories seems more appropriate to store the configuration for different CI platforms that require them ; some projects choose to hide everything that is not useful for the build process but here it does seem to be so). Are there advantages of using .ci/ directory? - Moreover having a "fedora-test.run" (or "fedora-test.sh", I am more used to .sh extension for shell scripts) enables to easily reproduce tests on a local development machine using "vagrant init fedora/32-cloud-base && vagrant ssh" + "sudo /vagrant/.../fedora-test.run". Such a command could be documented in the header of the shell script. - Right now, there are many things in .travis.yml. This file could be split in shell script(s) if that reduces duplication. - To verify the download of Fedora cloud image, instead of hard-coding its SHA256 digest, you could download the checksum file which is signed using GnuPG and check its signature, as described on https://alt.fedoraproject.org/cloud/ Cheers, Nicolas
