Jenkins Jobs for KubeVirt lab validation

Introduction

Jenkins is an open-source automation server that allows to define jobs, triggers, etc to validate that certain conditions are met.

Jobs can run either after a trigger has been received (for example from a repo merge or PR), periodically to validate that a previous ‘validated’ job is still ‘valid’ or even manually to force refresh of information.

Community repositories

Outside of the main KubeVirt binaries, there are other repos that are involved in the project ecosystem have tests to validate the information provided on them.

The community repositories include:

Those repos contain useful information for new users, like the try-it scenarios, the Laboratories, Katacoda scenarios, Community supporting files (like logos, proposals, etc).

The jobs

Our Jenkins instance is hosted at CentOS OpenShift instance and it’s available at https://jenkins-kubevirt.apps.ci.centos.org/

There, we’ve two jobs we’re currently refining to get better results:

Cloud Image Builder, which builds, according to the repo defined above contents what the AWS, GCP and Minikube images contain (binaries, KubeVirt version, Minikube version).
- The resulting AWS images are copied to each region.
- The resulting GCP images are also copied
- The resulting Minikube image is used for lab validation
Lab Validation which uses above created images with the contents of the /tests folder at Kubevirt.github.io repository to spin up instances and validate that the contents of the labs are valid

Both tests can be executed periodically (by default each day), causing a repository rescan to detect new changes and later validation of them and only on branch master.

If you’re curious about what Jenkins does, check the file JenkinsFile at the root of each repository:

Both of them define pipelines so that runs can be executed in parallel for each one of the environments: GCP, AWS, Minikube.

Cloud Image Builder

Cloud Image Builder has primarily two steps:

Build takes most of the logic, as it prepares virtctl and kubectl binaries and then for each one of the environments it executes the required ansible playbooks:

${environment}-provision.yml: Which creates the VM instance on the provider (for Minikube, it’s a VM inside GCP)
${environment}-setup.yml: Which configures the VM instance (repositories, packages, first-boot script, KubeVirt installation, virtctl binaries, etc)
${environment}-mkimage.yml: Which creates an image out of the instance generated by steps above
${environment}-publish.yml: Which, for GCP and AWS, publishes the generated image in above step

Once the images have been published, the jobs end and instances are removed from the providers.

Lab Validation

Lab Validation is meant to check that the labs described in the website are working on the three platforms (GCE, AWS, Minikube).

In opposition to KubeVirt Tutorial, it doesn’t use mdsh yet for extracting the actual commands out of the lab text and uses ansible playbooks to imitate the lab execution:

In addition, it contains files for also setting up the instance for running the tests (${environment}-provision.yml) and doing the later cleanup ($environment-cleanup.yml).

The first playbook, does create a new instance on the environment being checked using the images created by the Cloud Image Builder, so this means that not only the labs are validated, but also the images generated are validated to detect possible defects like missing binaries, wrongly installed software, etc.

The biggest part on the lab validation is with the lab.sh script, which accepts the lab being executed and the environment as parameters, and takes care of provisioning the instance, run the lab and perform cleanup afterwards.