Thomas Monjalon <tho...@monjalon.net> writes: > We have a public Coverity scan triggered by John for the community: > https://scan.coverity.com/projects/dpdk-data-plane-development-kit > Note there is a tool to help with this task: > > http://thyrsus.com/gitweb/?p=coverity-submit.git;a=shortlog;h=refs/tags/1.13 > > I see two issues with this scan: > - it is run manually > - not all code is scanned currently > > Note that we should be able to run one scan per day for free: > https://scan.coverity.com/faq#frequency > > With David, we looked at automating the Coverity scan, > with the help of Travis automation: > https://scan.coverity.com/travis_ci > Such automation cannot be configured on the existing Coverity project.
Why not? > I tried to open a new Coverity project connected to our GitHub. I don't know that it will work. Either you'll need a separate GitHub, or you'll need to use a special branch. > I have a very poor confidence in Coverity/Travis/GitHub integration. > I will explain below why. Hrrm.. lots of projects use it. And they do just what you prescribe below (skipping jobs/builds when on the coverity branch). > 1/ The instructions were wrong. In this command, there are two mistakes: > openssl s_client -connect https://scan.coverity.com:443 | > sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | > sudo tee -a /etc/ssl/certs/ca- > For the record, a proper a simpler command is: > true | openssl s_client -connect scan.coverity.com:443 | > openssl x509 | > sudo tee -a /etc/ssl/certs/ca-certificates.crt Okay, that's fixable. > 2/ The coverity scan is triggered as a job addon. > The rest of the job must be cancelled with this tricky patch: > > -script: ./.ci/${TRAVIS_OS_NAME}-build.sh > +script: if [ "${COVERITY_SCAN_BRANCH}" != 1 ] ; then > ./.ci/${TRAVIS_OS_NAME}-build.sh ; fi More than that, because we probably also want: if ([[ "${TRAVIS_JOB_NUMBER##*.}" == "1" ]] && [[ "${TRAVIS_BRANCH}" == "coverity_scan" ]]); then ./.ci/${TRAVIS_OS_NAME}-build.sh ; fi That will only do one job (which solves 3/ below) > 3/ We need only to prepare the source code once per day. > But our .travis.yml has many jobs which must be dropped or ignored. > > 4/ A big encrypted token must be added in the configuration: > # encrypted COVERITY_SCAN_TOKEN > - secure: "VgRYG9N5adKkM9/QpPgswn1c+VXS1mFVN0vgdjuC/bDv2x4u...etc..." Why it's a problem? > 5/ The addon is triggered when pushing to a specific branch > (adding config for the record): > coverity_scan: > project: > name: "DPDK/dpdk" > notification_email: test-rep...@dpdk.org > build_command_prepend: "meson build -Dexamples=all" > build_command: "ninja -C build" > branch_pattern: coverity_scan > > 6/ This attempt failed with this log (no more information): > $ export PROJECT_NAME=DPDK/dpdk > Coverity Scan analysis selected for branch coverity_scan. > Coverity Scan API access denied. Check $PROJECT_NAME and > $COVERITY_SCAN_TOKEN. Probably there is an issue with the token + PROJECT_NAME. > > So I am giving up with Travis+Coverity. > The only benefit of Travis is to have a central build configuration. > So when a driver is enabled in Travis, it would be scanned in Coverity. > Note: Coverity does a build step to prepare the sources. I can try to assist with this if you've not completely abandoned the idea. > > Now the question: how can we better configure the community Coverity scan? > I propose to set it up in our community lab. > Comments? Suggestions? Since we do have something working, but it's manual, is there a way to at least make it happen automatically? Maybe some cron job?
