CI: Add workflow_dispatch to workflows that still lack it

[kinkie]

Manually triggering a workflow rerun is handy when troubleshooting. Our
coverity-scan.yaml workflow already has a workflow_dispatch trigger.

[kinkie]

@rousskov I suspect that right now our queue is stuck because all eligible PRs are queued to run the checks defined in quick.yaml, however that workflow had been disabled (I don't know by whom or why), so the trigger events passed by without engaging it.
The workflow is meant to be triggered on push or PR, but if I were to push, approvals would be lost and would have to be re-granted. This PR would allow manually running these workflows if we ever were to find ourselves again in this situation, as well as allowing to un-stick it

[rousskov]

@rousskov I suspect that right now our queue is stuck because all eligible PRs are queued to run the checks defined in quick.yaml, however that workflow had been disabled (I don't know by whom or why)

I have not changed any configuration settings since you have started working on fixing CodeQL (and I would have disclosed those changes if I were to do them). I do not see any signs¹ of a disabled workload in this repository right now (and this PR tests did run). Did you re-enable it?

If at all possible, please start sharing any changes to repository configuration, especially if they were not previously discussed. CC: @yadij.

so the trigger events passed by without engaging it. The workflow is meant to be triggered on push or PR, but if I were to push, approvals would be lost and would have to be re-granted. This PR would allow manually running these workflows if we ever were to find ourselves again in this situation, as well as allowing to un-stick it

As you know from recent exchanges, I fought for adding this useful trigger. Thank you for adding it to the remaining workloads!

I have adjusted PR title/description to remove the false implication that all workloads lacked this trigger. I also removed a statement regarding permissions required to use this trigger because, AFAICT, it can be used by non-owners in certain cases (and that is OK!).

Footnotes

1. FWIW, you can see how a disabled workload is reported at https://github.com/measurement-factory/squid/actions ↩

[kinkie]

@rousskov I suspect that right now our queue is stuck because all eligible PRs are queued to run the checks defined in quick.yaml, however that workflow had been disabled (I don't know by whom or why)

I have not changed any configuration settings since you have started working on fixing CodeQL (and I would have disclosed those changes if I were to do them). I do not see any signs1 of a disabled workload in this repository right now (and this PR tests did run). Did you re-enable it?

Yes, I did.

If at all possible, please start sharing any changes to repository configuration, especially if they were not previously discussed. CC: @yadij.

Sure.
So far I have just disabled CodeQL checks, after trying pointlessly to reconfigure them.

so the trigger events passed by without engaging it. The workflow is meant to be triggered on push or PR, but if I were to push, approvals would be lost and would have to be re-granted. This PR would allow manually running these workflows if we ever were to find ourselves again in this situation, as well as allowing to un-stick it

As you know from recent exchanges, I fought for adding this useful trigger. Thank you for adding it to the remaining workloads!

No worries. In fact, in hindsight, I am surprised this is not on by default

I have adjusted PR title/description to remove the false implication that all workloads lacked this trigger. I also removed a statement regarding permissions required to use this trigger because, AFAICT, it can be used by non-owners in certain cases (and that is OK!).

Thanks

Footnotes

1. FWIW, you can see how a disabled workload is reported at https://github.com/measurement-factory/squid/actions ↩

[rousskov]

The workflow is meant to be triggered on push or PR, but if I were to push, approvals would be lost

It does not really matter in this case (we have enough folks to quickly re-approve those PRs), but pushing an empty PR commit does not invalidate past PR approvals. GitHub apparently added that behavior in 2023, and I have just successfully tested that with #1966 (commit 4edfc20).

[rousskov]

kinkie added M-cleared-for-merge S-could-use-an-approval and removed S-waiting-for-author labels

@kinkie, would you mind addressing my change requests before merging?