databricks/tests-1

databricks/tests-1

Description: Kata Containers tests, CI, and metrics

License: Apache-2.0

Stars: 0

Forks: 2

Open issues: 1

Created: 2021-09-29T03:57:14Z

Pushed: 2024-06-04T17:46:32Z

Default branch: main

Fork: yes

Parent repository: kata-containers/tests

Archived: no

README:

Kata Containers tests

• [Kata Containers tests](#kata-containers-tests)
• [Getting the code](#getting-the-code)
• [Test Content](#test-content)
• [CI Content](#ci-content)
• [Centralised scripts](#centralised-scripts)
• [CI setup](#ci-setup)
• [Controlling the CI](#controlling-the-ci)
• [Detecting a CI system](#detecting-a-ci-system)
• [Breaking Compatibility](#breaking-compatibility)
• [CLI tools](#cli-tools)
• [Developer Mode](#developer-mode)
• [Write a new Unit Test](#write-a-new-unit-test)
• [Run the Kata Containers tests](#run-the-kata-containers-tests)
• [Requirements to run Kata Containers tests](#requirements-to-run-kata-containers-tests)
• [Prepare an environment](#prepare-an-environment)
• [Run the tests](#run-the-tests)
• [Running subsets of tests](#running-subsets-of-tests)
• [Metrics tests](#metrics-tests)
• [Kata Admission controller webhook](#kata-admission-controller-webhook)
• [Using Vagrant to test your code changes](#using-vagrant-to-test-your-code-changes)

This repository contains various types of tests and utilities (called "content" from now on) for testing the Kata Containers code repositories.

Getting the code

$ go get -d github.com/kata-containers/tests

Test Content

We provide several tests to ensure Kata-Containers run on different scenarios and with different container managers.

1. Integration tests to ensure compatibility with:

• Kubernetes
• Containerd

2. Stability tests 3. Metrics 4. VFIO

CI Content

This repository contains a [number of scripts](/.ci) that run from under a "CI" (Continuous Integration) system.

Centralised scripts

The CI scripts in this repository are used to test changes to the content of this repository. These scripts are also used by the other Kata Containers code repositories.

The advantages of this approach are:

• Functionality is defined once.
• Easy to make changes affecting all code repositories centrally.

• Assurance that all the code repositories are tested in this same way.

CI scripts also provide a convenient way for other Kata repositories to install software. The preferred way to use these scripts is to invoke make with the corresponding install- target. For example, to install CRI-O you would use:

$ make -C install-crio

Use make list-install-targets to retrieve all the available install targets.

CI setup

> WARNING: > > The CI scripts perform a lot of setup before running content under a > CI. Some of this setup runs as the root user and could break your developer's > system. See [Developer Mode](#developer-mode).

Controlling the CI

GitHub Actions

Kata Containers uses GitHub Actions in the Kata Containers repos. All those actions, apart from the one to test kata-deploy, are automatically triggered when a pull request is submitted. The trigger phrase for testing kata-deploy is /test_kata_deploy.

Jenkins

The Jenkins configuration and most documentation is kept in the CI repository. Jenkins is setup to trigger a CI run on all the slaves/nodes when a /test comment is added to a pull request. However, there are some specific comments that are defined for specific CI slaves/nodes which are defined in the Jenkins config.xml files in the `` XML element in the CI repository.

Specific Jenkins job triggers

Some jobs like a particular distro, feature or architecture can be triggered individually, the specific job triggers information can be found in the Community repository.

Detecting a CI system

The strategy to check if the tests are running under a CI system is to see if the CI variable is set to the value true. For example, in shell syntax:

if [ "$CI" = true ]; then
: # Assumed to be running in a CI environment
else
: # Assumed to NOT be running in a CI environment
fi

Breaking Compatibility

In case the patch you submit breaks the CI because it needs to be tested together with a patch from another kata-containers repository, you have to specify which repository and which pull request it depends on.

Using a simple tag Depends-on: in your commit message will allow the CI to run properly. Notice that this tag is parsed from the latest commit of the pull request.

For example:

Subsystem: Change summary

Detailed explanation of your changes.

Fixes: #nnn

Depends-on:github.com/kata-containers/kata-containers#999

Signed-off-by:

In this example, we tell the CI to fetch the pull request 999 from the kata-containers repository and use that rather than the main branch when testing the changes contained in this pull request.

CLI tools

This repository contains a number of [command line tools](cmd). They are used by the [CI](#ci-content) tests but may be useful for user to run stand alone.

Developer Mode

Developers need a way to run as much test content as possible locally, but as explained in [CI Setup](#ci-setup), running *all* the content in this repository could be dangerous.

The recommended approach to resolve this issue is to set the following variable to any non-blank value **before using *any* content from this repository**:

export KATA_DEV_MODE=true

Setting this variable has the following effects:

• Disables content that might not be safe for developers to run locally.
• Ignores the effect of the CI variable being set (for extra safety).

You should be aware that setting this variable provides a safe *subset* of functionality; it is still possible that PRs raised for code repositories will still fail under the automated CI systems since those systems are running all possible…