With everything else set up, it’s time to finally enable Coverity Scan during the CI/CD process. You may already have GitLab CI set up. If not, it’s fairly simple to add. You just add a .gitlab-ci.yml file to your repository with the build instructions.
Those build instructions will be based on your own project’s build instructions, of course. As with the manual first submission, you run your normal build under the cov-build tool.
Here’s a template for your .gitlab-ci.yml file. You tell it you want it only to run on your coverity and master branches (since the variables won’t be available anywhere else). Then you provide a build script that downloads the Coverity Scan tools, extracts them, uses them to run your build, then submits the result.
- dnf update -y
- dnf install -y git autoconf automake libtool make curl
- curl -o /tmp/cov-analysis-linux64.tgz https://scan.coverity.com/download/linux64
--form project=$COVERITY_SCAN_PROJECT_NAME --form token=$COVERITY_SCAN_TOKEN
- tar xfz /tmp/cov-analysis-linux64.tgz
- cov-analysis-linux64-*/bin/cov-build --dir cov-int make -j4
- tar cfz cov-int.tar.gz cov-int
- curl https://scan.coverity.com/builds?project=$COVERITY_SCAN_PROJECT_NAME
--form token=$COVERITY_SCAN_TOKEN --form email=$GITLAB_USER_EMAIL
--form email@example.com --form version="`git describe --tags`"
--form description="`git describe --tags` / $CI_COMMIT_TITLE / $CI_COMMIT_REF_NAME:$CI_PIPELINE_ID "
Obviously, the part where it installs the dependencies, runs the autogen.sh and configure scripts, and then runs make might vary in your project. You can also tweak precisely what you put in your version and description to your liking. They’re just cosmetic and show up in the Coverity tools as your snapshot information.
Commit this file and push to your coverity branch. You should be able to watch the CI job proceed, and hopefully end with “Build successfully submitted.”
As the coverity branch is protected, you can’t force-push to it when you have something you want to test. But you can delete the branch, and its protected status is still remembered. Then you can push to it when you want to test something.
I haven’t worked out how to get pull requests automatically scanned, but I do a test pull and then push to my coverity branch for testing, and see the results that way. By doing this, I’ve already caught my first bugs in PRs that I wouldn’t otherwise have spotted.
About the Synopsys Software Integrity Community
The Synopsys Software Integrity Community is the place to go for Synopsys users and those interested in learning more about building faster, more-secure software. Take advantage of free tutorials and articles, and connect with like-minded peers.