Skip to content

Latest commit

 

History

History
70 lines (44 loc) · 4.11 KB

Testing.md

File metadata and controls

70 lines (44 loc) · 4.11 KB

Testing for Infrastructure Tools

This document will include all of the ways in which testing is done in the infrastructure repository.

Vagrant Playbook Check

The Vagrant Playbook Check (VPC) job is used to test changes made to the Windows and Linux playbooks.

The job is built in our Jenkins server. The job runs a user's fork of the infrastructure repository onto the supported operating systems using Vagrant virtual machines. The vagrant files for the supported operating systems can be found here.

Currently, the supported x86-64 systems are:

  • Windows 2012 and 2022
  • Debian 8 and 10
  • Ubuntu 16.04, 18.04, 20.04 and 22.04
  • CentOS 6, 7 and 8
  • Solaris 10
  • Fedora 35

Qemu Playbook Check

The QEMU Playbook Check (QPC) job is similar to the VPC job except it is not limited to x86-64 virtual machines.

It is built in our Jenkins server. The job itself runs this script.

Currently, the supported platorms are:

  • Ubuntu 18.04 on ppc64le, aarch64 and s390x
  • Debian 11 on riscv64
  • Debian 10 on aarch64
  • Debian 8 on arm32

Github workflows

These jobs run automatically when a pull request is submitted. The files for these jobs can be found here.

Platforms

If a pull request contains changes to the playbooks, this workflow will be triggered automatically. It will execute the playbook changes on the supported platforms:

Docker Build Images

This workflow job executes playbook changes inside a CentOS 6 and Alpine 3 docker container which it builds during the job.

The workflow file can be found here.

QEMU Playbook Check

Similar to the job that runs in our Jenkins server but this job runs in a github workflow.

The supported platforms are:

  • Ubuntu 18.04 on aarch64, ppc64le and s390x
  • Ubuntu 20.04 on riscv64
  • Debian 10 on aarch64

The workflow file can be found here.

Docker Static Checks

This github workflow is triggered when changes are made to the dockerfiles responsible for building our Static Docker containers.

If a pull request contains changes to any of the dockerfiles, the workflow will attempt to build the docker containers. It will pass if the containers build without error.

The file for this workflow can be found here.

AWX

Though primarily the infrastructure team uses AWX to execute the playbooks onto our build and test machines as a means of patching, we also use AWX to test changes made to playbooks by executing the changes onto any of the infrastructure machines.

Our AWX server is hosted here.