GitLab

This now uses a script installed on the Runner machine that performs a more sophisticated analysis of the diagnostics generated by the underlying cppcheck tool. Recognising that many components already trigger multiple cppcheck diagnostics, this script effectively filters them out, to permit us to focus on any new ones introduced in new work.

When a CI pipeline is launched on a branch or tag ref (including on push events, not limited to when an MR has been opened) this script normally analyses at least two commits (the one pointed at by the ref, and its first or only parent, unless there isn't one). In the common case that the commit is not yet on the default branch (or more specifically, when you're testing a fork project, on the default branch of the project it's forked from) then the script also analyses all commits back to their common ancestor. This usually corresponds to the set of commits that would be included in an MR.

For each commit, the number of each diagnostics of each type in each file is compared with those in the commit's first (or only) parent (if any). If the number increased, then information is printed to the job log. Diagnostics can be suppressed in a number of ways; if and only if the number of diagnostics that are not suppressed has also increased will the overall job status be considered a failure.

Suppressions use a wildcarded format, and can refer either to the diagnostic name (as printed in red in the log), the filename, the file-and-line spec (in the format <filename>:<line>) or the file-and-diagnostic spec (in the format <filename>:<diagnostic>). Suppressions can be undone by the use of a leading '-' character. Suppressions are space-separated and can be specified by any of the following methods:

• placing a line like this in a commit log (which only affects that commit):

  Disable cppcheck for myfile.c:123.

• placing a line like this in the variable declarations in .gitlab-ci.yml (this persists for all future commits, so it's best not to specify line numbers here):

  CPPCHECK_WHITELIST: "myfile.c subdir/*.c portability/*"

• assigning a value to CPPCHECK_WHITELIST when launching a pipeline manually

Some diagnostics are also suppressed globally; the list of such suppressions is expected to be refined over time.

If you need more information to help understand why any diagnostic is being triggered, it can be helpful to manually launch a pipeline with the environment variable VERBOSE set to 1.

Trial runs on actively-developed components indicate that in practice, it will be rare that a commit that is ready for merging will need to suppress any diagnostics. The most likely scenario in which one will be required is in the event that a new submission uses a construct that triggers a "false positive" in which cppcheck incorrectly infers a fault. These are not unheard of, but are typically fixed in a later revision of the tool. To avoid the need to use inline suppression markers for these - which we would typically want to remove at a later date when cppcheck is upgraded - it is therefore recommended that any such examples be dealt with using a suppression in the commit log.

Obsoletes !13 (closed).

[Edit 2023-01-19: formatting only]