Testing/CI: Difference between revisions

From QEMU
Line 3: Line 3:
= Current Status =
= Current Status =


The current status of the master branch can be included on any page by using template <pre>{{CIStatus}}</pre>
The current status of the master branch can be included on any page by using [[Template:CIStatus|CIStatus template]]:
 
{{CIStatus}}


There is also a [[Template:CustomCIStatus|custom template]] that you can use on your own page to track personal branches and provide a handy summary.
There is also a [[Template:CustomCIStatus|custom template]] that you can use on your own page to track personal branches and provide a handy summary.

Revision as of 12:00, 13 March 2019

Continuous Integration for the project is a distributed affair spread across a number of public CI services as well as some additional tests run on company infrastructure. There is a strong preference for tests to be integrated with our existing build system. This makes it easy for developers to run the tests directly in their own environment.

Current Status

The current status of the master branch can be included on any page by using CIStatus template:

System Focus Status
GitLab CI Majority of CI testing (builds x86 & cross), various check targets https://gitlab.com/qemu-project/qemu/badges/master/pipeline.svg [1]
Cirrus CI FreeBSD, MacOS and Windows MSYS2 compile and test https://api.cirrus-ci.com/github/qemu/qemu.svg [2]
Travis non-x86 hosts, mostly deprecated qemu.png?branch=master&file=qemu.png [3]
Coverity Static analysis https://scan.coverity.com/projects/378/badge.svg?flat=1&foo=qemu.svg [4]
Patchew Apply and test patches as they are sent on the mailing list. https://patchew.org/QEMU/badge.svg [5]
Documentation Build the RST portions of the doc/ subtree https://readthedocs.org/projects/qemu/badge/?version=latest&foo=qemu.svg [6]

There is also a custom template that you can use on your own page to track personal branches and provide a handy summary.

Troublesome Tests

Some tests seem to be particularly good at intermitently failing on our CI setup. They are likely triggered by load that is not typically seen on a developer box. If you can help in replicating and tracking down the failures then please do so. Tests the regularly fail at random tend to be disabled to avoid adding too much noise to an already noisy system.

Problematic tests are tracked in the Gitlab Issue tracker nowadays.