On Thu, May 14, 2020 at 5:03 PM Nicolas Iooss <nicolas.iooss@xxxxxxx> wrote: > > 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 Yeah I was pretty happy with the timing it took to add this. But CI doesn't necessarily need to be fast. We run a huge test matrix, Travis only spins up a few at a time anyways. > 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! I was surprised too, I was expecting that to be disabled, when I cat cpuinfo, I was very happy. > > 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) I would love something like that (no idea what I am doing), but it doesn't get rid of polling for network. We have to wait for the sshd to be ready. > - 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? No benefit, just did something. They can live wherever.... > - Moreover having a "fedora-test.run" (or "fedora-test.sh", I am more > used to .sh extension for shell scripts) enables to easily reproduce and be named whatever.... > 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. That sounds good, I like being able to do that. I have no idea what vagrant is. You could say im ignorant to vargrant! > - Right now, there are many things in .travis.yml. This file could be > split in shell script(s) if that reduces duplication. Yep I agree. Thats how I run all my other projects, I dislike large travis.yml files, but I don't want to take on that workload right now, ideally get this working and then port the other stuff. > - 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/ Yeah I saw that. Thats why I had that verify link in the TODO comment: https://alt.fedoraproject.org/en/verify.html > > Cheers, > Nicolas Thank you, appreciate your feedback
