Add coverity support to workflow #26

yasslbk · 2025-02-27T09:57:03Z

This PR adds Coverity support to the build workflow.
We need to add the needed secrets at a repository level.
We can restrict Coverity to publish only results of main branch.

MathisMARION · 2025-02-27T11:25:25Z

.github/workflows/build.yaml

I think this deserves a separate workflow.

Also do we even want to automatically run Coverity on every PR/push? (I don't know the deal that we have or how much it costs)

I will let you choose on this.

Can you move this into a separate workflow then? This will make it easy to tweak the run condition without affecting the regular build.

Also we will be able to use jobs.<job_id>.if instead of jobs.<job_id>.steps[*].if.

.github/workflows/build.yaml

MathisMARION · 2025-02-27T11:32:19Z

.github/workflows/build.yaml

+          COVERITY_SCAN_TOKEN: ${{ secrets.COVERITY_SCAN_TOKEN }}
+        run: |
+          # Download toolbox
+          COVERITY_URL="https://scan.coverity.com/download/cxx/linux64"


Why use an environment variable?

Indeed, you can probably replace all these lines by something like:

curl https://scan.coverity.com/download/cxx/linux64 \ --form token=${{ secrets.COVERITY_SCAN_TOKEN }} \ --form project=wisun-br-linux | tar -xC /opt ln -sfn /opt/coverity*/bin/coverity /bin

MathisMARION · 2025-02-27T11:34:50Z

.github/workflows/build.yaml

+          tar -xf coverity.tar.gz -C coverity --strip-components=1
+          rm -fr coverity.tar.gz
+          # For the current shell session
+          export PATH=$(pwd)/coverity/bin:$PATH


I would prefer either:

Install coverity in a standard directory (ie. /usr/bin, /usr/local/bin or alike).

Use an absolute path when calling Coverity tools.

Yes, this can work also.

MathisMARION · 2025-02-27T11:35:18Z

.github/workflows/build.yaml

+          export PATH=$(pwd)/coverity/bin:$PATH
+          coverity --version
+          # For the upcoming shell sessions
+          echo "$(pwd)/coverity/bin" >> $GITHUB_PATH


Why is this necessary?

Make sure coverity exists then simplify the next call of cov-build.

MathisMARION · 2025-02-27T11:36:25Z

.github/workflows/build.yaml

+        env:
+          COVERITY_SCAN_TOKEN: ${{ secrets.COVERITY_SCAN_TOKEN }}
+          COVERITY_SCAN_EMAIL: ${{ secrets.COVERITY_SCAN_EMAIL }}
+          COVERITY_SCAN_VERSION: ${{ github.sha }}


Do we need to use env vars?

Note: I now understand the need for secrets, but is it necessary for the SHA?

Not necessary, there is plenty of other ways to do it, the aim here was reusability by other teams working on open sources projects.
But let me point smt: It's common practice to use env variables in CI/CD tools.
Environment variables are ephemeral and exist only during pipeline execution. No persistence.
Most importantly, defining parameters as environment variables enhances reusability and flexibility, allowing different users or projects to run workflows with custom values without modifying the core script or commands or stages.

If we want something generic and reusable, the good way is to write an action. Maybe in the future we could have a Silabs action for Coverity if we have common steps.

btw, there seems to be an official Coverity GitHub action, I don't know how usable it is:
https://documentation.blackduck.com/bundle/bridge/page/documentation/c_github-coverity.html

I prefer relying on simple commands directly over using GitHub Actions.

GA abstract too much, making it feel like "magic" or "black box".
Reproducing workflows locally isn’t straightforward for developers—unless you use nektos/act, which isn’t easy to setup nor to use.

For me, it's the same logic as with Jenkins plugin: the less you rely on it, the happier you are.

Fair point, it is nice to view the Workflow as a list of commands that one can execute locally by copy-pasting.

I don't know much about Coverity, but it looks quite similar to SonarQube in being "magic / black box".
Sure you download tools, but you have no idea what they do besides produce data in a proprietary format that you then upload to a web platform for processing. Maybe I am wrong, as I have not looked in the details. Anyway, I'm diverging.

jerome-pouiller · 2025-02-27T11:39:17Z

.github/workflows/build.yaml

+        run: |
+          # Download toolbox
+          COVERITY_URL="https://scan.coverity.com/download/cxx/linux64"
+          wget -q $COVERITY_URL --post-data "token=${COVERITY_SCAN_TOKEN}&project=wisun-br-linux" -O coverity.tar.gz --no-check-certificate


Why no-check-certificate?

Locally, I couldn't check the certificate under the Silabs network, and this issue would also apply to self-hosted runners. We can assume that we won't use self-hosted runners for public repositories, and therefore, for Coverity, we don't need that flag.
However, I wanted to note the first point somewhere.

jerome-pouiller · 2025-02-27T11:40:28Z

.github/workflows/build.yaml

+          tar -xf coverity.tar.gz -C coverity --strip-components=1
+          rm -fr coverity.tar.gz
+          # For the current shell session
+          export PATH=$(pwd)/coverity/bin:$PATH


ln -sfn $(pwd)/coverity/bin/coverity /usr/bin, so you can drop the pain with $PATH

Do you mean ln -sfn $(pwd)/coverity/bin/ /usr/bin ?
Because, the goal is to facilitate the call to toolbox (cov-build, cov-analyze ...) not only coverity.

Then, ln -sfn $(pwd)/coverity/bin/cov* /usr/bin

* For main branch, download toolbox, build wsbrd using coverity then publish results. * Make sure cov commands are stored in /opt/coverity and accessible by creating a symlink to /usr/local/bin.

yasslbk · 2025-02-27T15:36:22Z

V2:

Run Coverity only for main branch.
Coverity's download, build and publish are done a the end. (we create another job called coverage in the same file: link).
Coverity is stored in a folder named independently of its version, this would reduce maintenance.

MathisMARION · 2025-02-28T16:40:42Z

.github/workflows/build.yaml

Can you move this into a separate workflow then? This will make it easy to tweak the run condition without affecting the regular build.

Also we will be able to use jobs.<job_id>.if instead of jobs.<job_id>.steps[*].if.

MathisMARION · 2025-02-28T16:43:31Z

.github/workflows/build.yaml

+          COVERITY_SCAN_EMAIL: ${{ secrets.COVERITY_SCAN_EMAIL }}
+          COVERITY_SCAN_VERSION: ${{ github.sha }}
+        run: |
+          tar czf cov-int.tgz cov-int


What does "int" mean here?

MathisMARION · 2025-02-28T16:52:20Z

.github/workflows/build.yaml

+               --form email="$COVERITY_SCAN_EMAIL" \
+               --form [email protected] \
+               --form version="$COVERITY_SCAN_VERSION" \
+               --form description="Coverity scan results for commit $COVERITY_SCAN_VERSION" \


Is this description necessary? It currently does not provide much information since the version is already provided. I could not even find where this description can be read on the frontend 😅

MathisMARION · 2025-03-03T13:49:48Z

.github/workflows/build.yaml

+               --form token="$COVERITY_SCAN_TOKEN" \
+               --form email="$COVERITY_SCAN_EMAIL" \
+               --form [email protected] \
+               --form version="$COVERITY_SCAN_VERSION" \


Should we use something more human friendly than a SHA? The output of wsbrd --version uses git describe.

MathisMARION reviewed Feb 27, 2025

View reviewed changes

jerome-pouiller reviewed Feb 27, 2025

View reviewed changes

yasslbk force-pushed the wip/yla/ci branch 4 times, most recently from 05d1b98 to 76daf49 Compare February 27, 2025 15:33

ci: add coverity to the build workflow

5e72728

* For main branch, download toolbox, build wsbrd using coverity then publish results. * Make sure cov commands are stored in /opt/coverity and accessible by creating a symlink to /usr/local/bin.

yasslbk force-pushed the wip/yla/ci branch from 76daf49 to 5e72728 Compare February 27, 2025 15:35

MathisMARION reviewed Mar 3, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add coverity support to workflow #26

Add coverity support to workflow #26

yasslbk commented Feb 27, 2025 •

edited

Loading

MathisMARION Feb 27, 2025

yasslbk Feb 27, 2025

MathisMARION Feb 28, 2025

MathisMARION Feb 27, 2025

jerome-pouiller Feb 27, 2025 •

edited

Loading

MathisMARION Feb 27, 2025 •

edited

Loading

yasslbk Feb 27, 2025

MathisMARION Feb 27, 2025

yasslbk Feb 27, 2025

MathisMARION Feb 27, 2025

MathisMARION Feb 27, 2025

yasslbk Feb 27, 2025 •

edited

Loading

MathisMARION Feb 27, 2025

yasslbk Feb 27, 2025

MathisMARION Feb 27, 2025 •

edited

Loading

jerome-pouiller Feb 27, 2025

yasslbk Feb 27, 2025

jerome-pouiller Feb 27, 2025

yasslbk Feb 27, 2025

jerome-pouiller Feb 27, 2025

yasslbk commented Feb 27, 2025

MathisMARION Feb 28, 2025

MathisMARION Feb 28, 2025

MathisMARION Feb 28, 2025

MathisMARION Mar 3, 2025

Add coverity support to workflow #26

Are you sure you want to change the base?

Add coverity support to workflow #26

Conversation

yasslbk commented Feb 27, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jerome-pouiller Feb 27, 2025 • edited Loading

Choose a reason for hiding this comment

MathisMARION Feb 27, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yasslbk Feb 27, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MathisMARION Feb 27, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yasslbk commented Feb 27, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yasslbk commented Feb 27, 2025 •

edited

Loading

jerome-pouiller Feb 27, 2025 •

edited

Loading

MathisMARION Feb 27, 2025 •

edited

Loading

yasslbk Feb 27, 2025 •

edited

Loading

MathisMARION Feb 27, 2025 •

edited

Loading