Run coverity if there was any commit in the week

[simo5]

No description provided.

[simo5]

@oerdnj after you showed me how to run cov scan on pkcs11-provider I wanted to revive the scans for this project.
Is there any trick in pulling the (admittedly huge) tarball?

See the action script, it should just work, but what I get is a 0 length tar ball instead.

I manually tried the curl command locally and it works, so I do not understand what's wrong. Unfortunately the actions script does not log anything so I can't tell where the error lays.

[oerdnj]

@oerdnj after you showed me how to run cov scan on pkcs11-provider I wanted to revive the scans for this project. Is there any trick in pulling the (admittedly huge) tarball?

See the action script, it should just work, but what I get is a 0 length tar ball instead.

I manually tried the curl command locally and it works, so I do not understand what's wrong. Unfortunately, the actions script does not log anything so I can't tell where the error lays.

This (usually) happens when the token or the project name is wrong...

If you go to https://scan.coverity.com/projects/gssproxy/builds/new, there's an exact CURL line that needs to be used. It's unintuitive, because for pkcs11prov it was "PKCS#11 Provider" (urlencoded) instead of pkcs-11-provider (from URL).

[simo5]

This (usually) happens when the token or the project name is wrong...

The project name is correct, it is a very simple "gssproxy"

If you go to https://scan.coverity.com/projects/gssproxy/builds/new, there's an exact CURL line that needs to be used. It's unintuitive, because for pkcs11prov it was "PKCS#11 Provider" (urlencoded) instead of pkcs-11-provider (from URL).

As I said I tested the curl command locally and authorization works.
And we can see it from the CI run as well, if it were an uth problem the first "HEAD" operation would already fail, but it does not apparently ...

Scratching my head....

[simo5]

I think I may know why this is not working, I think github is not giving out the secret token to the pull request, because the workflow is being changed there, so it could try to steal it.

I just pushed the commit onto my fork main tree after adding the secrets to my fork, and it seems to be downloading the huge tarball. After all previously the test run would fail pretty quickly, while now it is stuck there on the download step.

So I am going to assume this will resolve itself once I merge the code, and can't test it as part of a PR.

[simo5]

Indeed it succeeded and ran the scan from my fork.
So I'll consider this one good and merge it.

[oerdnj]

Oh, right. I also tested this on my fork's main branch for this reason. I've just forgot about this.