Code coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. Enabling this feature increases the size of the build and slows some operations, which is why this feature is not optimal for production builds. However, it can be enabled for test runs of CKI builds.
This feature is only available for Trusted Contributors using rpm.
To enable it, just add
.coverage to the merge request pipeline in
.gitlab-ci.yaml, below you can see an example:
... # regular pipelines merge_request_regular: extends: [.internal, .merge_request, .with_notifications, .trigger, .coverage] ...
... @@ -46,7 +46,7 @@ workflow: !reference [.workflow] merge_request_regular: extends: [.internal, .merge_request, .with_notifications, .rhel_common, - .trigger] + .trigger, .coverage] realtime_check_regular: extends: [.internal, .merge_request, .realtime_check_common,
Reminder: changes to
.gitlab-ci.yaml for enabling code coverage tests
should be removed before marking merge requests ready for review.
Getting the results
Links for both the coverage report and a tarball file which contains all the information necessary to generate the HTML report are provided. This will be linked directly in either the DataWarehouse for each gcov kernel result or it can be found by searching for the links within the GitLab job console log.
No matter which option is chosen, you will get the coverage report
and the tarball file which contents should look like (we will not guarantee a specific layout of the files).
$ tree . ├── report ├── info.txt ├── run.done.01 └── run.done.02 └── run.done.0X
For every architecture, you’ll see a GitLab
Click on the test job for each supported arch, go to the bottom and search for the coverage links.
Every checkout with coverage will be shown with the suffix
Inside of every build you will find the associated coverage links including the report and tarball file.Last modified July 19, 2022: Adjust GitLab URL for kpet-db (1cc81bd)