Jump to: navigation, search


HypervisorSupportMatrix | NovaVMware

Minesweeper CI

Minesweeper is continuous integration for Openstack running on VMware environments. In a nutshell, Minesweeper listens to newly created patchsets on review.openstack.org and runs the Tempest test suite on the patch. Currently Minesweeper is listening to Nova, Neutron and Cinder projects.

Current Status

Please see here for current status and a history of service disruptions.


See ThirdPartySystems/VMware_CI for contact details.

Triggered Paths

Minesweeper does not trigger on every single patchset because it sometimes it doesn't need to. Additionally, it is very costly for the Minesweeper CI to be running on non-crucial patches since 3 VMs need to be spun up everytime! For example, it doesn't trigger on unit tests because unit tests do not affect the outcome of the Tempest runs. We also don't trigger on doc changes or 3rd party driver changes. We match on the following patterns (if there are multiple modified files, only one of the them needs to match):


Excluded Tests

A small handful of Tempest tests are excluded from run because there are known issues or a specific feature may not be implemented. Information about these tests can be found here.

What to do when a build fails

Minesweeper votes a +1 for your patch when it passes. In the case of a failure, a +0 will be posted with a message that the build failed. When this happens, the best way to proceed is to follow these steps:

1. The build failure comment will be accompanied by a link to the build logs. Click to follow the link.

2. Open "testr_results.html.gz" and note the tests that failed. If the file is not present, then open "console.txt" and scroll to the bottom. If the message "Build was unsuccessful due to Infra-related issues" appears, go directly to step 4 (and optionally check the status page to see if Minesweeper is operational). Otherwise continue to step 3.

3. Navigate back to the logs directory and try to identify the cause of the failures using the screen logs. The best way to do this is go through the relevant logs and look for strings such as ERROR, CRITICAL, or Traceback.

4. If you are confident that your patch did not contribute to the error, then the last step is to issue a recheck. A recheck will essentially run your patch through the CI again in case the failure was caused by a transient bug, race condition, or cosmic rays. To issue a recheck, submit a comment with the following text: vmware-recheck-patch