---
layout: post
author: Pablo Iranzo Gómez
description: How Jenkins is leveraged for automation at KubeVirt Cloud Image Builder and Lab Validation
title: Jenkins Jobs for KubeVirt lab validation
navbar_active: Blogs
pub-date: October 31
pub-year: 2019
category: news
tags:
  [
    prow,
    infrastructure,
    kubevirt-tutorial,
    CI-CD,
    continuous integration,
    jenkins,
  ]
---

## Introduction

[Jenkins](https://jenkins.io/) 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:

- [KubeVirt website](https://github.com/kubevirt/kubevirt.github.io)
- [KubeVirt tutorial](https://github.com/kubevirt/kubevirt-tutorial)
- [Katacoda Scenarios](https://github.com/metal3-io/metal3-io.github.io)
- [Community repo](https://github.com/kubevirt/community)
- [Cloud Image Builder](https://github.com/kubevirt/cloud-image-builder)

Those repos contain useful information for new users, like the `try-it` scenarios, the Laboratories, [Katacoda scenarios](https://katacoda.com/kubevirt), 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 / https://jenkins-kubevirt.apps.ci.centos.org/job/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 / https://jenkins-kubevirt.apps.ci.centos.org/job/cloud-image-builder/job/master/lastSuccessfulBuild/artifact/new-images.json are copied to each region.
  - The resulting GCP images are also copied
  - The resulting Minikube image is used for lab validation
- Lab Validation / https://jenkins-kubevirt.apps.ci.centos.org/job/Lab%20Validation/ which uses above created images with the contents of the `/tests` folder at [Kubevirt.github.io repository](https://github.com/kubevirt/kubevirt.github.io/blob/abd315b2bcdabd2effa71fd3e6af1207d8fcbf42/tests) 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:

- <https://github.com/kubevirt/kubevirt.github.io/blob/abd315b2bcdabd2effa71fd3e6af1207d8fcbf42/Jenkinsfile>
- <https://github.com/kubevirt/cloud-image-builder/blob/master/Jenkinsfile>

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](https://github.com/kubevirt/cloud-image-builder/blob/master/shell/build.sh)
- [publish](https://github.com/kubevirt/cloud-image-builder/blob/master/shell/publish.sh)

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]({% post_url 2019-10-31-prow-jobs-for-kubevirt %}), 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:

- <https://github.com/kubevirt/kubevirt.github.io/blob/abd315b2bcdabd2effa71fd3e6af1207d8fcbf42/tests/ansible/lab1.yml>
- <https://github.com/kubevirt/kubevirt.github.io/blob/abd315b2bcdabd2effa71fd3e6af1207d8fcbf42/tests/ansible/lab2.yml>

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](https://github.com/kubevirt/kubevirt.github.io/blob/abd315b2bcdabd2effa71fd3e6af1207d8fcbf42/tests/shell/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.
