CodeSonar GitHub CI/CD Documentation

Overview

NOTICE: A private GitHub repository with a GitHub Enterprise license is required for this CodeSonar integration.

CodeSonar can be used within a GitHub Action workflow to automatically scan and analyze the source code in your GitHub repository.

This CodeSonar GitHub Integration package provides templates and examples to help you configure CodeSonar to analyze your code and report results to your GitHub repository web location.

This document provides a step-by-step walkthrough of a GitHub workflow which invokes a CodeSonar analysis from within a Docker container. After the walkthrough section, there is a section containing remarks on how to adapt the walkthrough to a Microsoft Windows platform.

Contents

Download

You can download the integration kit using this link which requires a support portal login.

Introduction

GitHub provides an Advanced Security Code scanning feature for reporting and managing code analysis results associated with a GitHub repository. Typically a code scan is configured to be done when new code is submitted to a GitHub Pull Request. Results of the CodeSonar analysis associated with a GitHub Pull Request can be viewed under the Pull Request "Checks" tab.incr_analysis.png

 

GitHub provides an upload-sarif workflow Action which allows code analysis results in SARIF format to be reported to GitHub. Since CodeSonar can generate a SARIF representation of your code analysis, you can use CodeSonar in a GitHub workflow to perform an automatic code scan.

Prerequisites

  • A basic understanding of Git and GitHub.
  • GitHub Enterprise account with Advanced Security enabled.
  • A private GitHub repository containing a code project to analyze.
  • CodeSonar 6.1 (or later).
  • A licensed CodeSonar hub website.
  • Access to a GitHub runner where you can install CodeSonar software and which can access your CodeSonar hub.
  • If using Docker on a Linux-based GitHub runner, you will need access to a Docker Registry where you can store Docker images containing CodeSonar software.

IMPORTANT: A private GitHub repository with a GitHub Enterprise license is required. Limitations imposed by the CodeSonar End User License Agreement (EULA) prohibit the use of CodeSonar for Code scanning on a public GitHub repository. Code scanning on a private GitHub repository requires a GitHub Enterprise license.

Walkthrough using Docker

The following guide walks through a setup procedure for analyzing your code with CodeSonar in Docker on Linux. Even if you are not planning to use Docker, many of the same steps will be required. Some additional remarks on troubleshooting and how to configure for Microsoft Windows, are provided later in this document. This walk-through contains 3 major sections:

  1. Setup a basic workflow to build your code in a GitHub workflow.
  2. Setup a workflow to perform CodeSonar analysis on a "base" branch of your code.
  3. Demonstrate an "incremental" analysis on a new branch relative to your base branch.

1: Basic Docker workflow setup

1.1. Configure a Linux/Docker Action runner:

You will need to install and configure a GitHub runner that will have access to your CodeSonar hub. For running workflow jobs with Docker, your GitHub runner will need to be installed on a Linux machine and it will need to be configured with all necessary permissions to run Docker containers. In addition, your runner will need to have access to a Docker registry where you are permitted to store images containing CodeSonar software.

See the GitHub documentation for specific setup instructions for self-hosted GitHub runners: https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners

1.2. Configure your GitHub Repository:

In your GitHub Repository, be sure "GitHub Advanced Security" and "Code scanning" are enabled in your GitHub repository "Settings" > "Security & Analysis" page.

1.3. Checkout your code:

If you haven't created a local repository yet, then clone it from the GitHub server now:

$ git clone https://github.com/_example_/_example_

1.4. Create a build environment Dockerfile:

Your Dockerfile must define a build environment that has the prerequisite software required to build your code. Depending on your source code requirements, a Dockerfile for building your code could be quite complex. A simple example Dockerfile for a C/C++ project that uses GCC and Make is provided below.

If you use this example Dockerfile, then you may need to specify additional apt-get packages corresponding to your source code build dependencies. Also note that this example Dockerfile uses Ubuntu as the base image. CodeSonar requires a glibc-based Linux distribution, so distributions like Alpine Linux will not work.

To use the example below, you should first create a new, empty directory and save the code to a file named "Dockerfile" in that directory.

FROM ubuntu:18.04
RUN apt-get update && apt-get install -y gcc make

1.5. Build, Tag, Push Docker image to registry:

You'll need to know the URL and login credentials for your Docker container registry. Example shell commands to build, tag, and push your image to the container registry are provided below. If you use these commands you will need to adjust the REGISTRY and BUILD_IMAGE variables appropriately.

$ REGISTRY=docker.example.com
$ BUILD_IMAGE=$REGISTRY/_example_/_example_build_image:v1
$ docker login $REGISTRY
$ docker build -t $BUILD_IMAGE "."
$ docker push $BUILD_IMAGE

1.6. Add Docker Registry credentials as GitHub Secrets:

The GitHub runner must be able to pull your Docker image from your Docker registry. We assume that your Docker registry requires a user name and password/token. We will configure the build job to retrieve registry credentials from the GitHub Secrets store. To add credential secrets, navigate to the "Settings" > "Secrets" page for your GitHub repository. Add new Secrets to store your Docker registry credentials:

Name of Secret Secret Value
DOCKER_USER example_registry_user_name
DOCKER_PASS XYZ123exampleTOKEN789

1.7. Create GitHub workflow definition to build your code:

Create subdirectory named ".github/workflows" in your repository. Add a new text file named "build.yml". Your build.yml file should look similar to the example below:

name: Build my project
on:
  push:
    branches:
      - main     # ✏️ Your default branch here
  pull_request:
    branches:
      - main     # ✏️ Your default branch here
env:
  PROJECT_NAME: ${{ github.event.repository.name }}
jobs:
  build:
    runs-on:
      - self-hosted
      - Linux
    container:
      image: docker.example.com/_example_/_example_build_image:v1   # ✏️ Your base Docker image here
      credentials:
        username: ${{ secrets.DOCKER_USER }}
        password: ${{ secrets.DOCKER_PASS }}
    timeout-minutes: 360
    steps:
      - uses: actions/checkout@v2
      - name: Configure the build scripts
        run: ./configure         # ✏️ Remove the lines for this step if your code does not use a ./configure script
      - name: Compile the Code
        run: make                # ✏️ Your build command here

1.8. Branch, add, commit, and push workflow definition:

Create a new branch named "basic_ci". You will use this basic_ci branch as the base for your analysis in subsequent steps. Add the "build.yml" file to this branch. Commit the file to the branch and push the branch to the GitHub server. See the example below.

$ git checkout -b "basic_ci"
$ git add .github/workflows/build.yml
$ git commit -m "Add workflow configuration for building code"
$ git push origin -u "basic_ci"

1.9. Open a Pull Request.

The git push command should print a URL to help you open a new Pull Request for your branch. You can copy-paste the URL into your web browser to initiate the Pull Request creation. If you don't see this URL or if you cannot use it, you can still open a Pull Request by navigating to the "branches" page of your GitHub repository.

1.10. Verify workflow executes successfully.

Your Pull Request page should contain a "Checks" tab page which shows the status of your workflow jobs. Inspect this page to verify that your workflow compiles your code successfully.

2: CodeSonar Analysis workflow setup

2.1. Extract CodeSonar GitHub Integration archive package.

If you have not yet downloaded the CodeSonar GitHub Integration package, please do so now. You can extract the contents of the archive package using the tar command.

For example:

$ tar xzf codesonar-github-integration-v1.1p0.tar.gz

2.2. Go to the "distro-image" subdirectory:

For example:

$ cd codesonar-github-integration-v1.1p0/distro-image

The distro-image subdirectory of the CodeSonar GitHub Integration package contains a Dockerfile that helps you install CodeSonar into a Docker image.

2.3. Copy CodeSonar install package into the "distro-image" directory:

Copy the entire (Linux) CodeSonar .tar.gz archive file into the distro-image directory (same directory as the Dockerfile). This will allow Docker to include the CodeSonar archive in the "build context" when you build your new analysis image.

For example, assuming distro-image is the current directory:

$ cp /path/to/codesonar-6.1p0.20210802-x86_64-pc-linux.tar.gz .

2.4. Build/Tag/Push CodeSonar analysis environment Docker image:

You can use the distro-image/Dockerfile to create a new "analysis" image which includes CodeSonar. Typically, you will not need to edit this Dockerfile, however you must provide several "build-arg" options when you use it. This Dockerfile uses your build environment image as a "base" upon which it will layer the additional CodeSonar software. This will allow the GitHub runner to execute CodeSonar and to let CodeSonar observe your build process.

If your CodeSonar hub has a certificate that is not automatically trusted by the CodeSonar commandline (such as a self-signed certificate), then you can add the hub certificate to the Docker image here. See the Troubleshooting section later in this document for instructions.

Example commands for building an image from the distro-image/Dockerfile are shown below. If you use these commands, you will need to change the REGISTRY, BUILD_IMAGE, CODESONAR_IMAGE, and CODESONAR_PACKAGE variables.

$ REGISTRY=docker.example.com
$ BUILD_IMAGE=$REGISTRY/_example_/_example_build_image:v1
$ CODESONAR_IMAGE=$REGISTRY/_example_/_example_analysis_image:v1
$ CODESONAR_PACKAGE=codesonar-6.1p0.20210802-x86_64-pc-linux.tar.gz
$ docker login $REGISTRY
$ docker build --tag $CODESONAR_IMAGE \
      --build-arg BASE_IMAGE=$BUILD_IMAGE \
      --build-arg CODESONAR_PACKAGE=$CODESONAR_PACKAGE \
      --build-arg TELEMETRY=1 \
      "."
$ docker push "$CODESONAR_IMAGE"

2.5. Add a copy of your GitHub server HTTPS certificate:

We are going to arrange for the analysis workflow to post a summary report to the conversation of your GitHub Pull Request.

The GitHub server certificate (either for an on-premesis GitHub Enterprise Server or for GitHub.com) may not be trusted by CodeSonar's Python interpreter cspython. To ensure that cspython can post the summary to the GitHub server, you will need to tell it which certificate it should expect. You must obtain a copy of the certificate and save it in Base64-encoded text (PEM) format. Most web browsers will allow you to do this. See the Troubleshooting section at the end of this document for details for how to download a certificate file.

Save the certificate file into your git repository as ".github/github.cert.pem".

2.6. Create GitHub workflow definition to run analysis:

Create a new text file in your repository .github/workflows subdirectory named "analyze.yml". Copy the example workflow file shown below into your new analyze.yml file.

Note that the example includes the branch basic_ci (which we created in a previous step) as a target for Pull Requests and git push events. This allows us to avoid altering the default branch (i.e. "main") in this walkthrough.

Note also that the example code shown below will authenticate with your CodeSonar hub using a password. This walkthrough will assume that you are using password authentication, however other methods will work with some minor modification.

name: Analyze my project
on:
  push:
    branches:
      - main     # ✏️ Your default branch here
      - basic_ci
  pull_request:
    branches:
      - main     # ✏️ Your default branch here
      - basic_ci
jobs:
  analyze:
    runs-on:
      - self-hosted
      - Linux
    container:
      image: docker.example.com/_example_/_example_analysis_image:v1   # ✏️ Your CodeSonar analysis Docker image here
      credentials:
        username: ${{ secrets.DOCKER_USER }}
        password: ${{ secrets.DOCKER_PASS }}
    env:
      GITHUB_CAFILE: ".github/github.cert.pem"  # ✏️ GitHub server HTTPS certificate file here
      GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
      PULL_REQUEST_ID: ${{ github.event.pull_request.number }}
      PROJECT_NAME: ${{ github.event.repository.name }}
      CSONAR_HUB_URL: "https://codesonar.example.com:8443"  # ✏️ Your CodeSonar hub URL here
      CSONAR_HUB_USER: "${{ secrets.CSONAR_HUB_USER }}"
      CSONAR_HUB_PASS: "${{ secrets.CSONAR_HUB_PASS }}"
      CSONAR_HUB_PWFILE: "codesonar.hub.pwfile"
      CODESONAR: /opt/codesonar/codesonar/bin/codesonar
      CSPYTHON: /opt/codesonar/codesonar/bin/cspython
      CSO_GITHUB: /opt/codesonar-github
    timeout-minutes: 360
    steps:
      - uses: actions/checkout@v2
      - name: Create Hub Credential File
        run: echo "$CSONAR_HUB_PASS" > "$CSONAR_HUB_PWFILE"
      - name: Configure the build scripts
        run: ./configure    # ✏️ Remove the lines for this step if your code does not use a ./configure script
      - name: Compile and Analyze the Code
        run: >
          "$CODESONAR" analyze
          -foreground
          -auth password
          -hubuser "$CSONAR_HUB_USER"
          -hubpwfile "$CSONAR_HUB_PWFILE"
          "$PROJECT_NAME"
          "$CSONAR_HUB_URL"
          make              # ✏️ Your build command here
      - name: Pull Analysis Results from CodeSonar Hub
        run: >
          "$CODESONAR" dump_warnings.py
          -o warnings.sarif
          --hub "$CSONAR_HUB_URL"
          -auth password
          -hubuser "$CSONAR_HUB_USER"
          -hubpwfile "$CSONAR_HUB_PWFILE"
          --project-file "$PROJECT_NAME"
          --sarif
          --src-root "$GITHUB_WORKSPACE"
          -t 7200
      - name: Cleanup Credential File
        run: shred -u "$CSONAR_HUB_PWFILE"
      - name: Push Analysis Results to GitHub
        uses: github/codeql-action/upload-sarif@v1
        with:
          sarif_file: warnings.sarif
      - name: Push Summary Report
        if: ${{ github.event.pull_request }}
        run: >
          "$CSPYTHON" "$CSO_GITHUB/sarif_summary.py"
          warnings.sarif
          "$CSONAR_HUB_URL"
          "$PROJECT_NAME"
          | "$CSPYTHON" "$CSO_GITHUB/push_github_pr_comment.py"
          --api-url "$GITHUB_API_URL"
          --cafile "$GITHUB_CAFILE"
          "$GITHUB_REPOSITORY"
          "$PULL_REQUEST_ID"
          GITHUB_TOKEN

2.7. Configure CodeSonar Hub credential Secrets:

Add some more secret values to your GitHub repository's Secrets store so that your analysis job can authenticate with your CodeSonar hub. Some example Secrets are shown below. The particular CodeSonar hub user specified in the CSONAR_HUB_USER Secret must have permissions to create a new analysis for your project.

Name of Secret Secret Value
CSONAR_HUB_USER example_hub_user_name
CSONAR_HUB_PASS example-password2!

2.8. Branch, add, commit, and push workflow definition:

If you have not yet enabled GitHub Advanced Security and Code scanning on your repository, be sure to do so now. See step 1.1.

Create a new branch off of basic_ci and name it "first_analysis". This new branch will store your analyze.yml workflow definition.

$ git checkout "basic_ci"
$ git checkout -b "first_analysis"
$ git add .github/github.cert.pem
$ git add .github/workflows/analyze.yml
$ git commit -m "Add analysis workflow configuration"
$ git push origin -u "first_analysis"

2.9. Open a Pull Request targeting your analysis base branch.

Important: When opening the new Pull Request, be sure to set basic_ci as the base branch. Do not use the default branch as the target of the Pull Request for this walkthrough.

2.10. Wait for analysis to complete, then check Code scanning results.

After the analysis completes, refresh the Pull Request "Checks" tab page to see the analysis results. You should see a "Code scanning results" item which can be expanded to reveal a "CodeSonar" item. Click the "CodeSonar" item to show the anaylsis results.

The analysis page will say "1 analysis not found". This is expected. Also, notice that the page shows a table of "Analyses" and in the row for the analyze.yml file it shows "Not found" in the "Base branch" column. We have not previously run an analysis on the basic_ci branch, yet GitHub wants to compare the analysis for your first_analysis branch against a previous analysis for the basic_ci branch. This condition always occurs when you run your first analysis on a base branch.

2.11. Notice the analysis summary message in Pull Request conversation.

The workflow was configured to post a summary of analysis results to your Pull Request's conversation page. This summary shows the number of warnings grouped into high/medium/low severity rankings. It also shows the most frequent warnings according to warning class.

summary_report.png

2.12. Merge your "first_analysis" Pull Request.

Merging your Pull Request will add the new analyze.yml file to your basic_ci branch. It will also cause GitHub to remember the analysis result from your Pull Request and use it as a "base" analysis for comparing "incremental" changes made later.

3: Incremental Analysis workflow setup

3.1. Pull merged commits and create a new branch from the base branch:

Pull the new merge commit for the basic_ci branch and create a new branch named update_code off of the basic_ci branch:

$ git checkout "basic_ci"
$ git pull origin
$ git checkout -b "update_code"

3.2. Edit your code; fix errors and add features:

This part is up to you. You can fix some bugs or otherwise extend your code. An easy way to change the analysis result for demonstration is to add a simple divide by zero error to your code, for example:

int test_function()
{
    return 1 / 0;
}

3.3. Add changes, commit and push:

Add you code changes, commit and push. For example:

$ git add _example_src_file_.c
$ git commit -m "Update the code"
$ git push origin -u "update_code"

3.4. Open a Pull Request that targets the analysis base branch:

When opening the Pull Request for your new update_code branch, be sure to set basic_ci as the base branch.

3.5. Wait for analysis to complete, then check results.

Your Code scanning results should show only the code alerts (i.e. CodeSonar warnings) that have changed relative to the analysis you previously did on the "basic_ci" branch.

3.6. End of walkthrough.

See the "Tips" section later in this document for some additional items to consider when setting up your workflows.


Tips for using Microsoft Windows

This section provides remarks on how to set up a workflow for a GitHub runner on a Microsoft Windows operating system.

Building and analyzing your code on a Microsoft Windows system is similar to the Docker instructions provided above. On a self-hosted GitHub runner you can install and configure your Windows software manually. You will need to install several programs on the Windows-based runner, including:

  • Compilers and tools required to build your code
  • CodeSonar
  • CodeSonar GitHub integration tools (see below)

Installing integration tools on Windows

The CodeSonar GitHub integration package is distributed as a compressed .tar.gz archive file. You may need to install a suitable program to extract the files if you do not have one available already.

The CodeSonar GitHub integration tools are found in the CodeSonar GitHub integration package under the distro-image\codesonar-github directory. You must copy these files to your Windows runner host. It is convenient to copy them into a subdirectory of your "Program Files\GrammaTech" directory. You may choose to copy the entire CodeSonar GitHub integration package contents. For example, in Powershell:

$ Copy-Item -Recurse "Path\To\codesonar-github-integration-1.1p0" "C:\Program Files\GrammaTech\"

Configuring workflow for Windows runner

GitHub workflows on Windows will use PowerShell by default. The following example shows how you might adapt the analyze.yml example file described in in the Docker walkthrough to Windows and PowerShell.

  • The example uses PowerShell to "source" a build.env.ps1 script that will initialize the build environment and program search paths. It is assumed that this script was previously created on the runner and that it modifies the $Env:PATH variable so that the build commands can be invoked. This example uses the "nmake" program to build the project.
  • Authentication with the CodeSonar hub is done here using a temporary password file initialized from the value of a GitHub repository Secret. The file is written in the system "Default" code page instead of PowerShell's usual default encoding (UTF-16).
  • The summary report is done in two steps to avoid text encoding issues when piping between subprocesses in PowerShell.
name: Analyze on Windows
on:
  push:
    branches:
      - main     # ✏️ Your default branch here
      - basic_ci
  pull_request:
    branches:
      - main     # ✏️ Your default branch here
      - basic_ci
jobs:
  analyze:
    runs-on:
      - self-hosted
      - Windows
    env:
      GITHUB_CAFILE: '.github\github.cert.pem'  # ✏️ GitHub server HTTPS certificate file here
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      PULL_REQUEST_ID: ${{ github.event.pull_request.number }}
      PROJECT_NAME: ${{ github.event.repository.name }}
      CSONAR_HUB_URL: "https://codesonar.example.com:8443"   # ✏️ Your CodeSonar hub URL here
      CSONAR_HUB_USER: "${{ secrets.CSONAR_HUB_USER }}"
      CSONAR_HUB_PASS: "${{ secrets.CSONAR_HUB_PASS }}"
      CSONAR_HUB_PWFILE: "codesonar.hub.pwfile"
      # ✏️ Path to CodeSonar installation:
      CODESONAR: 'C:\Program Files\GrammaTech\CodeSonar\codesonar\bin\codesonar.exe'
      CSPYTHON: 'C:\Program Files\GrammaTech\CodeSonar\codesonar\bin\cspython.exe'
      # ✏️ Path to CodeSonar GitHub Integration tools:
      CSO_GITHUB: 'C:\Program Files\GrammaTech\codesonar-github-integration-1.1p0\distro-image\codesonar-github'
    timeout-minutes: 360
    steps:
      - uses: actions/checkout@v2
      - name: Create Hub Credential File
        run: echo "$Env:CSONAR_HUB_PASS" | Out-File -Encoding Default "$Env:CSONAR_HUB_PWFILE"
      - name: Compile and Analyze the Code
        # ️️✏️ This command "sources" a fictional "build.env.ps1" script which sets environment variables for the build,
        #     you must modify this line to initialize your build environment.
        # ✏️ Your actual build command should be included on the last line of this `run` item:
        run: >
          . "$Env:SystemDrive\runner\etc\build.env.ps1" ;
          & "$Env:CODESONAR" analyze
          -foreground
          -auth password
          -hubuser "$Env:CSONAR_HUB_USER"
          -hubpwfile "$Env:CSONAR_HUB_PWFILE"
          "$Env:PROJECT_NAME"
          "$Env:CSONAR_HUB_URL"
          nmake
      - name: Pull Analysis Results from CodeSonar Hub
        run: >
          & "$Env:CODESONAR" dump_warnings.py
          -o warnings.sarif
          --hub "$Env:CSONAR_HUB_URL"
          -auth password
          -hubuser "$Env:CSONAR_HUB_USER"
          -hubpwfile "$Env:CSONAR_HUB_PWFILE"
          --project-file "$Env:PROJECT_NAME"
          --sarif
          --src-root "$Env:GITHUB_WORKSPACE"
          -t 7200
      - name: Cleanup Credential file
        run: del "$Env:CSONAR_HUB_PWFILE"
      - name: Push Analysis results to GitHub
        uses: github/codeql-action/upload-sarif@v1
        with:
          sarif_file: warnings.sarif
      - name: Generate Summary Report
        run: >
          & "$Env:CSPYTHON" "$Env:CSO_GITHUB\sarif_summary.py"
          warnings.sarif
          "$Env:CSONAR_HUB_URL"
          "$Env:PROJECT_NAME"
          --title "CodeSonar Analysis (Windows)"
          -o summary.md
      - name: Push Summary Report
        if: ${{ github.event.pull_request }}
        run: >
          & "$Env:CSPYTHON" "$Env:CSO_GITHUB\push_github_pr_comment.py"
          --api-url "$Env:GITHUB_API_URL"
          --cafile "$Env:GITHUB_CAFILE"
          "$Env:GITHUB_REPOSITORY"
          "$Env:PULL_REQUEST_ID"
          GITHUB_TOKEN
          summary.md

General Tips

Ensure your credential files will be cleaned-up

The examples provided in this document do not ensure that the CodeSonar hub credential file gets deleted in the case of a job step failure. For Docker, this problem is mitigated since the Docker container is presumed to be deleted and never reused after the job executes. For workflow jobs executed without Docker, the credential file may persist on the host file system until the next job executes on the runner.

You can use the jobs.<job_id>.steps[*].continue-on-error keyword in your workflow to prevent your analysis steps from aborting, but you will still need to force a step failure after the credentials are deleted so that you will know if a failure occurred. Unfortunately, if you use continue-on-error and force a failure in a later step you will not have an accurate view of which job actually failed when you look at the GitHub UI.

See the "warning_demo" example in the CodeSonar GitHub integration package for some code that demonstrates how to ensure that the credential file gets removed.

Consider adjusting the GitHub Action job timeout

GitHub Action/job timeout duration default is 360 minutes (6 hours). You can configure this timeout with the jobs.<job_id>.timeout-minutes keyword in your workflow .yml file. The maximum is 4320 minutes (3 days). You may need to increase the timeout in order to avoid unpleasant surprises later.

Consider adjusting the CodeSonar SARIF download timeout

The analysis workflow examples shown here use the CodeSonar dumpwarnings.py subcommand to download the warning data from the CodeSonar hub in SARIF format. The SARIF document contains comprehensive information and can take a long time to generate. The examples here set a timeout (with the -t option) of 7200 seconds (2 hours), which should be relatively safe. However, you may need to increase this number if your build is especially large and/or the analysis is especially time-consuming.

Number of warnings (alerts) is limited to 5000

GitHub will only show 5000 warnings (alerts). GitHub will silently fail to accept any of your warnings if you have more than 25,000. You may need to add a filter to the codesonar dump_warnings.py command in your workflow file in order to reduce the number of warnings submitted to GitHub. This can be done with the --visible-warnings option. It is possible to make a custom warning filter if necessary. See the CodeSonar manual page for codesonar dump_warnings.py for more information.

Optionally reduce CodeSonar Docker image size

The distro-image/Dockerfile includes several build-arg options which allow you to omit portions of the CodeSonar installation within the Docker image. This allows you to substantially reduce the size of the CodeSonar Docker image. See the contents of the Dockerfile for more information.

Troubleshooting

Trusted HTTPS Certificate for CodeSonar Hub

The CodeSonar commandline tools must trust the HTTPS certificate used by your CodeSonar hub.

If you are using Docker and your CodeSonar hub certificate is self-signed or is not otherwise trusted by the CodeSonar commandline tools installed in your Docker image, then you can add your hub certificate to the CodeSonar installation when you build the CodeSonar Docker image. Replace the placeholder distro-image/cacert.pem file with a copy of your hub's HTTPS certificate in .pem format before building & pushing your CodeSonar Docker image.

The .pem certificate can be downloaded from the CodeSonar hub. Go to "Settings" > "HTTP" > "Configure HTTPS".

Download an HTTPS Certificate using your Web Browser

You may need to aquire an HTTPS Certificate for the GitHub server. One way to get this certificate is to download it using your web browser.

For example, in Google Chrome:

  1. Navigate to your GitHub repository web page.
  2. Click the "lock" icon on the left side of the browser address bar to open the connection security menu.
  3. Click the "Certificate" menu item to open the certificate viewer popup.
  4. Click the "Details" tab.
  5. Click the "Export..." button.
  6. Be sure to select "Base64-encoded ASCII" as the certificate type. (You can export "single certificate" or "certificate chain"; either one will work).

Self-hosted Docker on Linux

If your GitHub runner is self-hosted on Linux, then you must install the GitHub runner software on the host operating system in order to run GitHub workflow jobs inside a Docker container. The GitHub runner process cannot both run inside a Docker container and also execute Docker-based workflow jobs. That is, the GitHub runner does not support "Docker-in-Docker". GitHub may add support for this in the future.

GitHub Actions error: "Workflow runs completed with no jobs"

Double-check that the branch names specified in the workflow on:pull_request and on:push keywords indeed contain the target branch of your Pull Request (or push). Typical default branch names for Git are main and master. For the walkthrough in this setup guide, the "basic_ci" branch that you created must also be included.


Was this article helpful?
0 out of 0 found this helpful

Articles in this section

GrammaTech Resource Library
Welcome to GrammaTech's resource library. Here you will find useful information about software development in the IoT era, where devices must not only function with impeccable quality and safety but also remain resilient to cyber attacks.
Shift Left Academy
Shift Left Academy is an educational resource to help implement a security first approach. Shift Left focuses on finding and preventing defects and security vulnerabilities early in the software development process
Blog
Posts by topic including static analysis, software assurance, and binary analysis