CI: add coverity scan scheduled

[chipitsine]

this requires adding a variable COVERITY_SCAN_TOKEN to settings

also, I'd suggest issue new token since current one (or is it fake ?) exposed in

cppcheck/tools/run-coverity.sh

Line 15 in eed9c4d

--form token=e74RRnWR6BVsn5LKdclfcA \

[danmar]

nice! let's try this..

[chipitsine]

we need to check for the next scheduled run.
fingers crossed.

[firewave]

I do not understand why we need this at all. Coverity is triggered automatically on each commit (except that it has been broken for ages now - see https://trac.cppcheck.net/ticket/12009) - or did that behavior change?

And if that changed - scheduling this doesn't seem to make much sense at all as it would mostly be a bunch of commits in-between scans making it hard to pin down the actual commit which introduced an issue. Or is Coverity able to handle that`.

In a perfect world a PR would give feedback from this so we would not introduce any new warnings at all...but let's take this one step at a time.

we need to check for the next scheduled run. fingers crossed.

You could just make it triggerable by allowing workflow_dispatch.

[chipitsine]

I do not understand why we need this at all. Coverity is triggered automatically on each commit (except that it has been broken for ages now - see https://trac.cppcheck.net/ticket/12009) - or did that behavior change?

it was not triggered on push. no idea on that

And if that changed - scheduling this doesn't seem to make much sense at all as it would mostly be a bunch of commits in-between scans making it hard to pin down the actual commit which introduced an issue. Or is Coverity able to handle that`.

coverity has it's own daily limits, it may be easy to overcome them with multiple push during a day

Build Limits

The number of weekly builds per project are as follows:

Up to 28 builds per week, with a maximum of 4 builds per day, for projects with fewer than 100K lines of code
Up to 21 builds per week, with a maximum of 3 builds per day, for projects with 100K to 500K lines of code
Up to 14 builds per week, with a maximum of 2 build per day, for projects with 500K to 1 million lines of code
Up to 7 builds per week, with a maximum of 1 build per day, for projects with more than 1 million lines of code

In a perfect world a PR would give feedback from this so we would not introduce any new warnings at all...but let's take this one step at a time.

we need to check for the next scheduled run. fingers crossed.

You could just make it triggerable by allowing workflow_dispatch.

that makes sense indeed

[firewave]

it was not triggered on push. no idea on that

It was triggered. It just failed. Unfortunately I can no longer check this since that added workflow cleared that error. As I only have limited permissions the actual error was not visible to me but might have been to @danmar. That's also why the ticket is lacking details beside the last time we had a successful run.

It now got updated results but as it was working for over 9(!) years without this workflow beforehand I have the feeling something else is wrong and this is basically just a brute-force workaround. I would like to know why it stopped working and not simply ignore that just because we get updated results now. Bugs disappearing without actually fixing something always make me anxious.

And if that changed - scheduling this doesn't seem to make much sense at all as it would mostly be a bunch of commits in-between scans making it hard to pin down the actual commit which introduced an issue. Or is Coverity able to handle that`.

coverity has it's own daily limits, it may be easy to overcome them with multiple push during a day

Thanks for the explanation. As it was "just working" before we never had to concern about that. Maybe it was just scheduling it by itself based on the limits.

[chipitsine]

@firewave , sorry, I'm not a part of https://trac.cppcheck.net/ticket/12009
maybe you can talk to those who are involved into that

[danmar]

@firewave sorry for late reply.. but Coverity was not triggered on every commit before. It was executed daily on the cppcheck1.osuosl.org server.
Of course it's much better to run it in the github action because everybody has access to the commands now.

[firewave]

It was executed daily on the cppcheck1.osuosl.org server.

Now it all makes much more sense.