jenkins: Add jenkins jobs for machine type Q35

[GabyCT]

These are the configs for the jenkins jobs for machine type Q35.

Fixes #143

Signed-off-by: Gabriela Cervantes [email protected]

[jodh-intel]

Please could you add an explanation into the commit as to why CentOS was chosen? it wfm, but it would be useful to state why (even if that's just "we randomly decided to do this on CentOS" :)

[grahamwhaley]

I'm going to have a stab/guess that maybe CentOS was chosen to get some more/broader coverage in our 'CI test matrix'. Which, brings to my mind, @chavafg - maybe we should have the CI test matrix drawn out in a doc somewhere (obvious) on here - to show what combinations of things (rootfs, image, vsock, network, distros, hypervisors) we test, and using which CI jobs. I guess that could be a large/complex table, but maybe that is the point - to show/document the complexity and coverage. It may also help us understand if all repos are treated equal (as I'm pretty sure they are not, and that is probably deliberate right now).

Taking a peek at Jenkins, and choosing what is probably the most complex case (runtime), and only PR builds, I see maybe 11 PR jobs for the runtime.

wdyt?

[jodh-intel]

Agreed - such a doc would be very useful. In fact, why not make it a YAML document so it's human- and machine-readable and can be treated like a database?

[grahamwhaley]

Personally I was thinking of a nicely human readable table in a markdown doc on this repo front page - something immediately accessible to human eyes. We sort of already have the info in a machine readable way if we need - sure, it's all in jenkins config xml files, and maybe you can pull it from a REST interface on the jenkins server itself...
maybe we can have a tool that converts either of those into the human readable version, but I'm not sure it will be easy to extract all the info (like hypervisor name or storage/graph setup etc.) auto-magically.

[chavafg]

@GabyCT these jobs were renamed from the original centos jobs, please add the deletions of those here please.

[jodh-intel]

We've got precedent for both approaches as we have a number of yaml dbs including the versions database. But we also have tables like https://github.com/kata-containers/osbuilder/#platform-distro-compatibility-matrix.

Regarding turning yaml into a table, that should be easy as it would be a tweak to the golang tool on kata-containers/tests#1466.

We can start simple with a table in the README, but we should "define one and once only" - I hate out-of-date docs ;) Unfortunately, I think we're going to have that table go stale as we add/remove XML files. We might be able to detect that by:

• Adding a .ci/ to the ci repo ;)
• Updating https://github.com/kata-containers/tests/blob/master/.ci/static-checks.sh to add a test specifically for when xml files get added / removed in the ci repo to ensure "something sensible" happens to the table in the README. Might be a bit gnarly that's why I'd personally start with the YAML and just generate tables from it ;)

[chavafg]

@grahamwhaley @jodh-intel opened #145 to track that task

[GabyCT]

@chavafg changes applied