CodeChecker C++ Static Analysis action

GitHub Action to execute static analysis over using CodeChecker as its driver. For C-family projects (C, C++, Objective-C, CUDA, etc.), CodeChecker supports driving the static analysis programs of Clang. Several other static analysers' output can be integrated into CodeChecker through the report converter.

Overview (for C-family projects)

⚠️ CAUTION! This action has been written with commands that target Ubuntu-based distributions!

This single action composite script encompasses the following steps:

1. Obtain a package of the LLVM Clang suite's analysers, and CodeChecker.
2. (Optional) Log the build commands to prepare for analysis.
3. Execute the analysis.
4. Show the analysis results in the CI log, and create HTML reports that can be uploaded as an artefact. (Uploading is to be done by the user!)
5. (Optional) Check for the current commit introducing new bug reports against a known state. (Good for pull requests!)
6. (Optional) Upload the results to a running CodeChecker server. (Good for the main project!)

ℹ️ Note: Static analysis can be a time-consuming process. It's recommended that the static analysis step is not sequential with the rest of a CI execution, but either runs as its own job in a workflow, or a completely distinct workflow altogether.

Please ensure that your project is completely configured for a build before executing this action.

ℹ️ Note: Static analysers can rely on additional information that is optimised out in a true release build. Hence, it's recommended to configure your project in a Debug configuration.

Specifying the project to analyse

Add the job into your CI as follows. The two versions are mutually exclusive — you either can give a compilation database, or you instruct CodeChecker to create one.

Projects that can generate a JSON Compilation Database and build cleanly (no generated code)

Some projects are trivial enough in their build configuration that no additional steps need to be taken after executing configure.sh, cmake, or similar tools. If you are able to generate a compilation database from your build system without running the build itself, you can save some time, and go to the analysis immediately.

You can specify the generated compilation database in the logfile variable

job:
  steps:
    # Check YOUR project out!
    - name: "Check out repository"
      uses: actions/checkout@v2

    # Prepare a build
    - name: "Prepare build"
      run: |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

    # Run the analysis
    - uses: whisperity/codechecker-analysis-action@v1
      id: codechecker
      with:
        logfile: ${{ github.workspace }}/Build/compile_commands.json

    # Upload the results to the CI.
    - uses: actions/upload-artifact@v2
      with:
        name: "CodeChecker Bug Reports"
        path: ${{ steps.codechecker.outputs.result-html-dir }}

Projects that need to self-creating a JSON Compilation Database or require generated code

Other kinds of projects might rely heavily on generated code. When looking at the source code of these projects without a build having been executed beforehand, they do not compile — as such, analysis cannot be executed either.

In this case, you will need to instruct CodeChecker to log a build (and spend time doing the build) just before analysis.

You can specify the build to execute in the build-command variable.

job:
  steps:
    # Check YOUR project out!
    - name: "Check out repository"
      uses: actions/checkout@v2

    # Prepare a build
    - name: "Prepare build"
      run: |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses: whisperity/codechecker-analysis-action@v1
      id: codechecker
      with:
        build-command: "cd ${{ github.workspace }}/Build; cmake --build ."

    # Upload the results to the CI.
    - uses: actions/upload-artifact@v2
      with:
        name: "CodeChecker Bug Reports"
        path: ${{ steps.codechecker.outputs.result-html-dir }}

Breaking the build if there are static analysis warnings

If requested, the warnings output variable can be matched against to execute a step in the job which breaks the entire job if any static analysis warnings were emitted by the project.

ℹ️ Note: Due to static analysis being potentially noisy and the reports being unwieldy to fix, the default behaviour and recommendation is to only report the findings but do not break the entire CI.

To get the reports in a human-consumable form, they must be uploaded somewhere first, before the failure step fails the entire job!

job:
  steps:
    # Check YOUR project out!
    - name: "Check out repository"
      uses: actions/checkout@v2

    # Prepare a build
    - name: "Prepare build"
      run: |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses: whisperity/codechecker-analysis-action@v1
      id: codechecker
      with:
        build-command: "cd ${{ github.workspace }}/Build; cmake --build ."

    # Upload the results to the CI.
    - uses: actions/upload-artifact@v2
      with:
        name: "CodeChecker Bug Reports"
        path: ${{ steps.codechecker.outputs.result-html-dir }}

    # Break the build if there are *ANY* warnings emitted by the analysers.
    - name: "Break build if CodeChecker reported any findings"
      if: ${{ steps.codechecker.outputs.warnings == 'true' }}
      run: exit 1

Uploading results to a CodeChecker server

If your project hosts a CodeChecker server somewhere, the job can be configured to automatically create or update a run.

# It is recommended that storing only happens for PUSH events, and preferably
# only for long-term branches.
on:
  push:

job:
  steps:
    # Check YOUR project out!
    - name: "Check out repository"
      uses: actions/checkout@v2

    # Prepare a build
    - name: "Prepare build"
      run: |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses: whisperity/codechecker-analysis-action@v1
      id: codechecker
      with:
        build-command: "cd ${{ github.workspace }}/Build; cmake --build ."
        store: true
        store-url: 'http://example.com:8001/MyProject'
        store-username: ${{ secrets.CODECHECKER_STORE_USER }}
        store-password: ${{ secrets.CODECHECKER_STORE_PASSWORD }}
        # store-run-name: "custom run name to store against"

Acting as a CI gate on pull requests

CodeChecker is capable of calculating the difference between two analyses. If an analysis of the stable version of the project is stored (see above) to a server, a job for pull requests can be configured that automatically rejects a pull request if it tries to introduce new analysis findings.

To get the reports in a human-consumable form, they must be uploaded somewhere first, before the failure step fails the entire job!

on:
  pull_request:

runs:
  steps:
    # Check the pull request out! (In pull_request jobs, the checkout action
    # automatically downloads the "after-merge" state of the pull request if
    # there are no conflicts.)
    - name: "Check out repository"
      uses: actions/checkout@v2

    # Prepare a build
    - name: "Prepare build"
      run: |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses: whisperity/codechecker-analysis-action@v1
      id: codechecker
      with:
        build-command: "cd ${{ github.workspace }}/Build; cmake --build ."

        store: ${{ github.event_name == 'push' }}
        store-url: 'http://example.com:8001/MyProject'
        store-username: ${{ secrets.CODECHECKER_STORE_USER }}
        store-password: ${{ secrets.CODECHECKER_STORE_PASSWORD }}
        # Keep the names for 'store' and 'diff' in sync, or auto-generated!
        # diff-run-name: "custom run name to store with"

        diff: ${{ github.event_name == 'pull_request' }}
        diff-url: 'http://example.com:8001/MyProject'
        diff-username: ${{ secrets.CODECHECKER_DIFF_USER }}
        diff-password: ${{ secrets.CODECHECKER_DIFF_PASSWORD }}
        # diff-run-name: "custom run name to diff against"

    # Upload the potential new findings results to the CI.
    - uses: actions/upload-artifact@v2
      if: ${{ steps.codechecker.outputs.warnings-in-diff == 'true' }}
      with:
        name: "New introduced results Bug Reports"
        path: ${{ steps.codechecker.outputs.diff-html-dir }}

    - name: "Fail the job if new findings are introduced"
      if: ${{ steps.codechecker.outputs.warnings-in-diff == 'true' }}
      shell: bash
      run: |
        echo "::error title=New static analysis warnings::Analysed commit would introduce new static analysis warnings and potential bugs to the project"
        # Fail the build, after results were collected and uploaded.
        exit 1

Overview (for other analyses through the report-converter)

⚠️ CAUTION! This action has been written with commands that target Ubuntu-based distributions!

This single action composite script encompasses the following steps:

1. Obtain a package of CodeChecker.
2. Use the report-converter to convert other analysers' reports to CodeChecker's format.
3. Show the analysis results in the CI log, and create HTML reports that can be uploaded as an artefact. (Uploading is to be done by the user!)
4. (Optional) Check for the current commit introducing new bug reports against a known state. (Good for pull requests!)
5. (Optional) Upload the results to a running CodeChecker server. (Good for the main project!)

ℹ️ Note: Static analysis can be a time-consuming process. It's recommended that the static analysis step is not sequential with the rest of a CI execution, but either runs as its own job in a workflow, or a completely distinct workflow altogether.

Please refer to the documentation of the analyser of your choice for this. CodeChecker does NOT support driving the analysis through external tools, but if a successful analysis had been done, it can convert and store the results.

job:
  steps:
    # Check YOUR project out!
    - name: "Check out repository"
      uses: actions/checkout@v2

    # Perform the analysis. Details vary between analysers!
    # Example for "PyLint" added below!
    - name: "Analyse with PyLint"
      run: |
        sudo apt-get -y install pylint
        pylint -f json --exit-zero myproject > pylint_reports.json

    # Run the conversion
    - uses: whisperity/codechecker-analysis-action@v1
      id: codechecker
      with:
        report-converter: true
        original-analyser: "pylint"
        original-analysis-output: "pylint_reports.json"

    # Upload the results (after conversion by CodeChecker) to the CI.
    - uses: actions/upload-artifact@v2
      with:
        name: "CodeChecker Bug Reports"
        path: ${{ steps.codechecker.outputs.result-html-dir }}

Uploading results and acting as a CI gate

The report-converter tool converts the output of various analysers to the common format used by CodeChecker. Once the conversion is done, the rest of the action's features can execute in the same fashion as for C/C++ projects. Please refer to earlier parts of the documentation for the configuration of these features.

Action configuration

Versions to install

Build log configuration

🔖 Read more about CodeChecker log in the official documentation.

Analysis configuration

🔖 Read more about CodeChecker analyze in the official documentation.

Report configuration

🔖 Read more about CodeChecker parse in the official documentation.

Report conversion configuration

🔖 Read more about the report-converter in the official documentation.

Diff configuration

🔖 Read more about CodeChecker cmd diff in the official documentation.

🔓 Checking the analysis results against the contents of a server requires the PRODUCT_VIEW permission, if the server is requiring authentication.

Store configuration

🔖 Read more about CodeChecker store in the official documentation.

🔓 Storing runs to a server requires the PRODUCT_STORE permission, if the server is requiring authentication.

Action outputs to use in further steps

The action exposes the following outputs which may be used in a workflow's steps succeeding the analysis.