[ovs-dev] GitHub: Add Coverity scan as a daily GitHub action.

This patch adds a daily Coverity run for the OVS main branch
to the GitHub actions. The result of the runs can be found here:

  https://scan.coverity.com/projects/openvswitch

Before applying, we need to add the following two actions secrets
to the GitHub openvswitch project:

- COVERITY_SCAN_TOKEN; The secret token from the project page
- COVERITY_SCAN_EMAIL; The maintainer's email alias

Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
---
 .github/workflows/coverity.yml | 131 +++++++++++++++++++++++++++++++++
 Makefile.am                    |   1 +
 README.rst                     |   2 +
 3 files changed, 134 insertions(+)
 create mode 100644 .github/workflows/coverity.yml

On Tue, Apr 16, 2024 at 09:44:52AM +0200, Eelco Chaudron wrote:
> This patch adds a daily Coverity run for the OVS main branch
> to the GitHub actions. The result of the runs can be found here:
> 
>   https://scan.coverity.com/projects/openvswitch
> 
> Before applying, we need to add the following two actions secrets
> to the GitHub openvswitch project:
> 
> - COVERITY_SCAN_TOKEN; The secret token from the project page
> - COVERITY_SCAN_EMAIL; The maintainer's email alias
> 
> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>

Hi Eelco,

I'm fine with this patch in it's current form.

Acked-by: Simon Horman <horms@ovn.org>

But I do have a few questions.

1. Would it be useful to provide instructions to
   allow people to become involved in addressing warnings?

   It seems that a signup to scan.coverity.com is required
   to see information on warnings.

2. Is there any plan to address warnings?

3. See below.

> ---
>  .github/workflows/coverity.yml | 131 +++++++++++++++++++++++++++++++++
>  Makefile.am                    |   1 +
>  README.rst                     |   2 +
>  3 files changed, 134 insertions(+)
>  create mode 100644 .github/workflows/coverity.yml
> 
> diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
> new file mode 100644
> index 000000000..ae28920de
> --- /dev/null
> +++ b/.github/workflows/coverity.yml
> @@ -0,0 +1,131 @@
> +name: Coverity scan
> +on:
> +  schedule:
> +    - cron: '0 0 * * *'
> +
> +env:
> +  python_default: 3.12
> +
> +jobs:
> +  build-dpdk:
> +    env:
> +      dependencies: gcc libbpf-dev libnuma-dev libpcap-dev ninja-build pkgconf
> +      CC: gcc
> +      DPDK_GIT: https://dpdk.org/git/dpdk
> +      DPDK_VER: 23.11
> +    name: dpdk gcc
> +    outputs:
> +      dpdk_key: ${{ steps.gen_dpdk_key.outputs.key }}
> +    runs-on: ubuntu-22.04
> +    timeout-minutes: 30
> +
> +    steps:
> +    - name: checkout
> +      uses: actions/checkout@v4
> +
> +    - name: update PATH
> +      run: |
> +        echo "$HOME/bin"        >> $GITHUB_PATH
> +        echo "$HOME/.local/bin" >> $GITHUB_PATH
> +
> +    - name: create ci signature file for the dpdk cache key
> +      # This will collect most of DPDK related lines, so hash will be different
> +      # if something changed in a way we're building DPDK including DPDK_VER.
> +      # This also allows us to use cache from any branch as long as version
> +      # and a way we're building DPDK stays the same.
> +      run: |
> +        cat .ci/dpdk-* > dpdk-ci-signature
> +        grep -rwE 'DPDK_GIT|DPDK_VER' .github/ >> dpdk-ci-signature
> +        if [ "${DPDK_VER##refs/*/}" != "${DPDK_VER}" ]; then
> +            git ls-remote --heads $DPDK_GIT $DPDK_VER >> dpdk-ci-signature
> +        fi
> +        cat dpdk-ci-signature
> +
> +    - name: generate ci DPDK key
> +      id: gen_dpdk_key
> +      env:
> +        ci_key: ${{ hashFiles('dpdk-ci-signature') }}
> +      run: echo 'key=dpdk-${{ env.ci_key }}' >> $GITHUB_OUTPUT

The above two steps seem both complex and somewhat different to
the implementation in build-and-test.yml.

Would it be worth introducing some sort of helper to generate
the key? Perhaps a script that lives in .ci/

> +
> +    - name: cache
> +      id: dpdk_cache
> +      uses: actions/cache@v4
> +      with:
> +        path: dpdk-dir
> +        key: ${{ steps.gen_dpdk_key.outputs.key }}

...

On 4/16/24 09:44, Eelco Chaudron wrote:
> This patch adds a daily Coverity run for the OVS main branch
> to the GitHub actions. The result of the runs can be found here:
> 
>   https://scan.coverity.com/projects/openvswitch
> 
> Before applying, we need to add the following two actions secrets
> to the GitHub openvswitch project:
> 
> - COVERITY_SCAN_TOKEN; The secret token from the project page
> - COVERITY_SCAN_EMAIL; The maintainer's email alias
> 
> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> ---
>  .github/workflows/coverity.yml | 131 +++++++++++++++++++++++++++++++++
>  Makefile.am                    |   1 +
>  README.rst                     |   2 +
>  3 files changed, 134 insertions(+)
>  create mode 100644 .github/workflows/coverity.yml

Thanks, Eelco for bringing this up.  Though, continuing the
offline discussion, I'm not sure having coverity scans as
a GitHub action has any benefits for OVS community.

A few issues:

1. Reports are not available to people outside of the OVS
   Coverity project.  Adding everyone there doesn't seem
   reasonable.  Also a potential security concern.

2. Workflow cannot be used in forks due to organization secrets.
   (IIUC, current implementation will just fail once a day
   annoying people who didn't disable that workflow.)

3. Necessity to have secrets in the organization.  We currently
   don't have any, and from a security standpoint not having
   any secrets is always better.

4. A decent amount of code duplication for this workflow.
   (Reusable workflows maybe?)

In its current form, I think, the same functionality can be
provided by the 0-day robot that could submit sources once
a day for the scan.  And it could also send some emails with
build details if necessary (again, there may be some security
concerns in case coverity discovers a genuine security issue).

With the total amount of code in the project, IIUC, we could
submit up to 21 builds a week with no more than 3 per day
(Coverity claims that it checked just under 300K lines in OVS).
So, technically, we could create a bit more complex logic
for 0-day bot to run a check per patch set (probably, not per
patch though).  In most cases we would fit within the limit
with the current patch rate.  Maybe reserving one run a week
for the main branch.  Such logic would be harder to implement
with GHA.

All in all, using GHA just for scheduling of a job that wider
community can't take advantage of seems a little unjustified.

Thoughts?

Best regards, Ilya Maximets.