| Message ID | 20230728124005.177414-1-frank@lichtenheld.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [Openvpn-devel] GHA: new workflow to submit scan to Coverity Scan service | expand |
Hi, generally good, but... On Fri, Jul 28, 2023 at 02:40:05PM +0200, Frank Lichtenheld wrote: > index 00000000..0620f638 > --- /dev/null > +++ b/.github/workflows/coverity-scan.yml > @@ -0,0 +1,45 @@ > +name: coverity-scan > +on: > + schedule: > + - cron: '0 20 * * *' # Daily at 20:00 UTC > + workflow_dispatch: ... not sure this is the best way to approach the run limit, as we can have many days with no commits at all, so we'd waste credits. Maybe cache the last commit ID and only run coverity if this has changed? Or run it "on commit", but cache the current day, and only run it again on the next commit that's not on the same day? (My typical workflow is "you folks queue up patches, and then I find half a day of free time, and go merge&push as many as I can make sense of") gert
Am 11.08.23 um 17:12 schrieb Gert Doering: > Hi, > > generally good, but... > > On Fri, Jul 28, 2023 at 02:40:05PM +0200, Frank Lichtenheld wrote: >> index 00000000..0620f638 >> --- /dev/null >> +++ b/.github/workflows/coverity-scan.yml >> @@ -0,0 +1,45 @@ >> +name: coverity-scan >> +on: >> + schedule: >> + - cron: '0 20 * * *' # Daily at 20:00 UTC >> + workflow_dispatch: > > ... not sure this is the best way to approach the run limit, as > we can have many days with no commits at all, so we'd waste credits. > > Maybe cache the last commit ID and only run coverity if this has > changed? Or run it "on commit", but cache the current day, and only > run it again on the next commit that's not on the same day? > > (My typical workflow is "you folks queue up patches, and then I find > half a day of free time, and go merge&push as many as I can make sense of") You can get that behaviour but it is tricky. You have to resort tricks like this: https://github.com/orgs/community/discussions/26519 of saving something to a cache and then reading the cache on the next run and check if something changed. We can probably implement like that and then trigger on push too? Arne
On Fri, Aug 11, 2023 at 05:35:03PM +0200, Arne Schwabe wrote: > Am 11.08.23 um 17:12 schrieb Gert Doering: > > Hi, > > > > generally good, but... > > > > On Fri, Jul 28, 2023 at 02:40:05PM +0200, Frank Lichtenheld wrote: > > > index 00000000..0620f638 > > > --- /dev/null > > > +++ b/.github/workflows/coverity-scan.yml > > > @@ -0,0 +1,45 @@ > > > +name: coverity-scan > > > +on: > > > + schedule: > > > + - cron: '0 20 * * *' # Daily at 20:00 UTC > > > + workflow_dispatch: > > > > ... not sure this is the best way to approach the run limit, as > > we can have many days with no commits at all, so we'd waste credits. > > > > Maybe cache the last commit ID and only run coverity if this has > > changed? Or run it "on commit", but cache the current day, and only > > run it again on the next commit that's not on the same day? > > > > (My typical workflow is "you folks queue up patches, and then I find > > half a day of free time, and go merge&push as many as I can make sense of") > > You can get that behaviour but it is tricky. You have to resort tricks like > this: https://github.com/orgs/community/discussions/26519 of saving > something to a cache and then reading the cache on the next run and check if > something changed. We can probably implement like that and then trigger on > push too? I've basically implemented this now in v2 of the patch (just updated to v3 of cache action). This should address the resource waste concern and also remove unnecessary noise. I've still left the action to trigger on schedule instead of push. I think implementing rate limiting based on push is not worth the effort. Especially since it would often mean that if you have multiple pushes per day the end-result is actually likely to be scanned later since the first pushes eat your rate limit. If some changes should be scanned immediately you can always trigger the workflow manually. Otherwise once per day should be fine. Regards,
diff --git a/.github/workflows/coverity-scan.yml b/.github/workflows/coverity-scan.yml new file mode 100644 index 00000000..0620f638 --- /dev/null +++ b/.github/workflows/coverity-scan.yml @@ -0,0 +1,45 @@ +name: coverity-scan +on: + schedule: + - cron: '0 20 * * *' # Daily at 20:00 UTC + workflow_dispatch: + +jobs: + latest: + runs-on: ubuntu-latest + steps: + - name: Install dependencies + run: sudo apt update && sudo apt install -y liblzo2-dev libpam0g-dev liblz4-dev libcap-ng-dev libnl-genl-3-dev linux-libc-dev man2html libcmocka-dev python3-docutils libtool automake autoconf libssl-dev libpkcs11-helper1-dev softhsm2 gnutls-bin + - name: Checkout OpenVPN + uses: actions/checkout@v3 + + - name: Download Coverity Build Tool + run: | + wget -q https://scan.coverity.com/download/cxx/linux64 --post-data "token=$TOKEN&project=OpenVPN%2Fopenvpn" -O cov-analysis-linux64.tar.gz + mkdir cov-analysis-linux64 + tar xzf cov-analysis-linux64.tar.gz --strip 1 -C cov-analysis-linux64 + env: + TOKEN: ${{ secrets.COVERITY_SCAN_TOKEN }} + + - name: autoconf + run: autoreconf -fvi + - name: configure + run: ./configure --enable-pkcs11 + + - name: Build with cov-build + run: | + PATH=`pwd`/cov-analysis-linux64/bin:$PATH + cov-build --dir cov-int make + + - name: Submit the result to Coverity Scan + run: | + tar czvf openvpn.tgz cov-int + curl --form token=$TOKEN \ + --form email=$EMAIL \ + --form file=@openvpn.tgz \ + --form version="$GITHUB_SHA" \ + --form description="master" \ + https://scan.coverity.com/builds?project=OpenVPN%2Fopenvpn + env: + TOKEN: ${{ secrets.COVERITY_SCAN_TOKEN }} + EMAIL: ${{ secrets.COVERITY_SCAN_EMAIL }}
Not on every push due to submit limits. Change-Id: I302ccc82f9d5c43b58350bbbf7f16ad1c559248f Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com> --- .github/workflows/coverity-scan.yml | 45 +++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 .github/workflows/coverity-scan.yml