SDPT Lab 7

Week 7 Lab Activity: Adding a Static Analysis Quality Gate

Objective

Extend your Week 6 CI pipeline with a new lint stage that runs before the build and blocks Merge Requests on static analysis findings. By the end of this lab your pipeline gates code on three things: it must lint cleanly, it must compile, and it must pass tests.

Background

In Week 6 you built a CI pipeline with at least build and test stages. Today you are adding a lint stage as the first stage. A failure there skips later stages and blocks the MR.

You will use two complementary tools. cppcheck is a fast, pattern-based analyzer that runs from the command line on your source tree without needing your build to succeed; its strength is speed and a low false-positive rate. clang-tidy is a deeper AST-based analyzer built on top of Clang, which means it understands templates, overloads, lifetimes, and modern C++ semantics. It ships hundreds of configurable checks grouped into families such as bugprone-*, cert-*, cppcoreguidelines-*, modernize-*, performance-*, and readability-*. The full catalog is at https://clang.llvm.org/extra/clang-tidy/checks/list.html.

clang-tidy needs to know exactly how each file is compiled (include paths, defines, C++ standard). CMake produces that information for free if you set CMAKE_EXPORT_COMPILE_COMMANDS=ON, which writes a compile_commands.json to your build directory. To make clang-tidy run automatically on every compile, set the CMake variable CMAKE_CXX_CLANG_TIDY to a clang-tidy command line --- CMake will then invoke clang-tidy alongside the compiler on every C++ source file. To run cppcheck from a build target, wrap it in an add_custom_target definition.

clang-tidy is configured by a .clang-tidy YAML file at the repo root. The two important keys for this lab are Checks (a comma-separated glob list, prefix - to disable) and WarningsAsErrors (same syntax). The conventional pattern is to start with -* and then re-enable only the families you want, rather than enabling everything and trying to silence the noise.

Both tools support inline suppressions: // cppcheck-suppress <id> and // NOLINTNEXTLINE(<check>). Always pair a suppression with a comment explaining why. Unjustified suppressions are themselves a code smell.

For tool usage refer to cppcheck --help, man cppcheck, clang-tidy --help, and the check catalog linked above.

Tasks

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

1. Extend the build environment. Update your Dockerfile so the image installs both cppcheck and clang-tidy. Rebuild the image and verify both binaries respond to --version from inside a container. If your runner pulls the image from a registry, push the new tag.
2. Configure clang-tidy. Create .clang-tidy at the repository root. You must enable, at a minimum, the entire bugprone-* family and at least two specific checks from cppcoreguidelines-*. You must explicitly disable any check from those families that fires noisily on your existing code (e.g. some readability-identifier-length or cppcoreguidelines-pro-bounds-* checks are commonly muted in embedded code). Set WarningsAsErrors so any reported issue fails the build. Add a comment block at the top of the file explaining the rationale for your check selection --- this is part of the deliverable.
3. Wire clang-tidy into CMake. Modify CMakeLists.txt so that compile commands are exported and clang-tidy runs automatically on every C++ compile. Make sure the build still works for team members who do not have clang-tidy installed locally (hint: find_program can return a NOTFOUND value, and you can branch on that).
4. Add a cppcheck custom target. Define a CMake custom target named cppcheck that runs the tool on your source tree. Required flags: at minimum --enable=warning,style,performance,portability, --error-exitcode=1 (so it propagates failures), --inline-suppr (so your inline suppressions are honored), and --std=c++17 (or whatever your project uses). Decide for yourself whether to scan or skip the build directory, the test directory, and any third-party code.
5. Add the lint stage to GitLab CI. Edit .gitlab-ci.yml to add a new lint stage as the first stage. Add a job that runs cppcheck inside your updated Docker image. The job must fail the pipeline on any cppcheck finding. clang-tidy itself does not need a separate CI job, since wiring it into CMAKE_CXX_CLANG_TIDY means it already runs during your existing build job.
6. Clean up your existing code. Push your branch and let the pipeline run. If clang-tidy or cppcheck flags real issues in the Oven Controller, fix them properly. If you genuinely believe a finding is a false positive, suppress it inline with a justification comment --- but no more than two suppressions for this lab. Three or more suppressions almost always means you should fix the underlying problem instead.
7. Verify the gate fires. Once the pipeline is fully green, introduce a deliberate bug on your branch. Pick something the tools should catch: a memory leak, a null pointer dereference, an uninitialized read, a forgotten delete[], a use-after-move, a buffer overflow. Push the bug, confirm the lint or build stage fails, then preserve a copy of the relevant tool output (a job-log permalink in the MR description is sufficient). Revert the deliberate bug; your final pipeline must be green.
8. Measure the cost. Compare the wall-clock time of your full pipeline before and after this lab. Record both numbers and the percentage increase in the MR description, along with one sentence on whether the trade-off is worth it for this codebase. Be honest --- "the lint stage adds 4 minutes and we caught zero real bugs today" is a valid finding.
9. Review and merge. Open the MR and have a teammate review it. The reviewer should specifically check: the rationale comment in .clang-tidy, that any suppression has a justification, the visibility of the deliberate-bug pipeline run, and the cost measurement. Merge when approved.

Stretch tasks (optional, if you finish early)

Pick at most one. These will not gain you points but will make your project measurably more professional.

• Tighten the rules. Add a check from cert-* or clang-analyzer-* and resolve all findings.
• Explore MISRA. cppcheck ships an experimental misra addon. Run it against your code (you may need a rules text file --- see the cppcheck addons documentation), and report the top three findings together with the MISRA rule numbers they correspond to.
• Add a pre-commit hook. Configure either a Git pre-commit hook or the pre-commit framework to run cppcheck on staged files. This catches issues before they reach CI and saves runner time.
• Generate a SARIF report. Configure clang-tidy to emit findings in SARIF format and upload it as a GitLab CI artifact. This is how findings are typically aggregated across larger projects.

Deliverables

For this lab to be marked complete, your main branch must contain:

1. A Dockerfile that installs both static analysis tools.
2. A .clang-tidy file with a rationale comment and your chosen check set.
3. A CMakeLists.txt that exports compile commands, hooks clang-tidy into the build, and defines a cppcheck custom target.
4. A .gitlab-ci.yml with a lint stage running before the build stage.
5. A merged MR whose linked Issue (or MR description) contains:
   1. The cost measurement from Task 8.
   2. A reference to the failed pipeline from Task 7 and the green pipeline that followed.
   3. A justification for any inline suppression added during Task 6.

Common pitfalls

• clang-tidy reporting findings in third-party headers (Google Test, system headers, etc.). Constrain HeaderFilterRegex in .clang-tidy to match only your own paths.
• cppcheck warning about missing system headers. Add --suppress=missingIncludeSystem to your invocation.
• clang-tidy producing different findings on different machines. Almost always means compile_commands.json is missing or stale --- regenerate it after every CMake configure, and make sure the file is inside the build directory clang-tidy looks at.
• The pipeline timing out. clang-tidy is significantly slower than the compiler. If the full build now exceeds your runner's timeout, narrow your check set or scope HeaderFilterRegex more tightly.
• "It works on my machine but fails in CI." Almost always means your locally installed clang-tidy version differs from the one in the Docker image. The container is the source of truth.
• Suppressing checks instead of fixing code. If you find yourself adding a third suppression, stop and reconsider. The right action is almost always to fix the code, not to silence the tool.

Looking ahead

Next week we leave the CI pipeline alone for one session and focus on the architecture of your capstone: how the Raspberry Pi and the VM server actually communicate. Bring your design questions about the project.