Rework cppcheck job
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
<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_WHITELISTwhen 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
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]