Skip to content

rfmvh/tests-beaker

This branch is 290 commits behind cki-project/tests-beaker:master.

Folders and files

NameName
Last commit message
Last commit date

Latest commit

1e15729 · Jul 15, 2019
Feb 12, 2019
Jul 15, 2019
Jul 10, 2019
Jul 10, 2019
Jul 11, 2019
Jul 12, 2019
Jun 19, 2019
Mar 25, 2019
Jul 3, 2019
Jul 10, 2019
Jun 19, 2019
Apr 2, 2019
Feb 11, 2019
Jul 2, 2019
May 28, 2019
Apr 5, 2019
May 8, 2018
Jun 4, 2019
Jun 12, 2019
Feb 12, 2019

Repository files navigation

Beaker tasks used with skt runner

How to run tests

Here is a list of common prerequisites for all beaker tests. Test-specific dependencies and steps can be found in the README.md within each test's directory.

$ sudo wget -O /etc/yum.repos.d/beaker-client.repo https://beaker-project.org/yum/beaker-client-Fedora.repo
$ sudo wget -O /etc/yum.repos.d/beaker-harness.repo https://beaker-project.org/yum/beaker-harness-Fedora.repo
$ sudo dnf install -y beaker-client beakerlib restraint-rhts

Test onboarding

Currently, all onboarded tests must use the following combinations of result/status fields:

  • SKIP/COMPLETED if the test requirements aren't fulfilled (eg. test is running on incompatible architecture/hardware)
  • PASS/COMPLETED if the test finished successfully
  • WARN/ABORTED in case of infrastructure issues or other errors (eg. the test checks out a git repo and the git server is unavailable)
  • WARN/COMPLETED or FAIL/COMPLETED in case of any test failures, based on how serious they are (left to decide by test authors)

When onboarding a test, please check especially the point about infrastructure issues: a lot of tests simply report a warning if eg. external server can’t be reached and then continue. This kind of situation falls under infrastructure issues and the test must use the WARN/ABORTED combination, otherwise the infrastructure problem is reported to people as a bug in their code!

The order of Beaker tasks in the XML determines if the task is a preparation for the testing or a test. Anything after kpkginstall task is treated as a test and must follow the rules above. Anything except PASS before kpkginstall is treated as infrastructure issue. Machineinfo (to get HW specification) is ran before kpkginstall, so the same logic applies there. PANIC during kpkginstall means the kernel is bad (can't boot).

About

CI tests to run in Beaker

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • C 46.0%
  • Shell 42.6%
  • Makefile 7.0%
  • Python 4.4%