Infra: Consider running the Infra: CVE checks with every commit as well

[yeikel]

Issue submitter TODO list

• I've searched for an already existing issues here
• I'm running a supported version of the application which is listed here and the feature is not present there

Is your proposal related to a problem?

Currently, the "Infra: CVE checks" check is configured to run twice per month, and while that is great, it does not raise the constant awareness that CVE should raise.

For example, the latest run failed but it is only known if we navigate to the specific build check while main is considered to be healthy

Describe the feature you're interested in

We should extend the cve_checks.yml workflow to also run on pull requests and merges to main. It should continue to be a separate check

• Pull requests: Because we should not be introducing new dependencies with CVEs
• On Main : To raise awareness and serve as a continuous reminder that actions may be needed

Describe alternatives you've considered

Use the existing schedule and remember to check manually

Version you're running

318bcc9

Additional context

No response

[Haarolean]

Pull requests: Because we should not be introducing new dependencies with CVEs

I don't mind this one, would be nice to know if there's anything new in case of newly introduced dependencies.

On Main : To raise awareness and serve as a continuous reminder that actions may be needed

This one is questionable, considering we don't have much bandwidth to fix these issues too often. Like, #256 was open for half a year. Running this on every commit sounds like an extra noise.

@yeikel what do you think?

[yeikel]

Pull requests: Because we should not be introducing new dependencies with CVEs

I don't mind this one, would be nice to know if there's anything new in case of newly introduced dependencies.

On Main : To raise awareness and serve as a continuous reminder that actions may be needed

This one is questionable, considering we don't have much bandwidth to fix these issues too often. Like, #256 was open for half a year. Running this on every commit sounds like an extra noise.

@yeikel what do you think?

I agree that it would be noise if it not actioned, but I think that this is good noise. We should be more than aware than issues with CVE exist and I think that every commit is a good way to show that

[Haarolean]

Pull requests: Because we should not be introducing new dependencies with CVEs

I don't mind this one, would be nice to know if there's anything new in case of newly introduced dependencies.

On Main : To raise awareness and serve as a continuous reminder that actions may be needed

This one is questionable, considering we don't have much bandwidth to fix these issues too often. Like, #256 was open for half a year. Running this on every commit sounds like an extra noise.
@yeikel what do you think?

I agree that it would be noise if it not actioned, but I think that this is good noise. We should be more than aware than issues with CVE exist and I think that every commit is a good way to show that

aight, @yeikel wanna raise a PR for these changes?

[yeikel]

Pull requests: Because we should not be introducing new dependencies with CVEs

I don't mind this one, would be nice to know if there's anything new in case of newly introduced dependencies.

On Main : To raise awareness and serve as a continuous reminder that actions may be needed

This one is questionable, considering we don't have much bandwidth to fix these issues too often. Like, #256 was open for half a year. Running this on every commit sounds like an extra noise.
@yeikel what do you think?

I agree that it would be noise if it not actioned, but I think that this is good noise. We should be more than aware than issues with CVE exist and I think that every commit is a good way to show that

aight, @yeikel wanna raise a PR for these changes?

See #745

[Haarolean]

We need a '0' exit code in case of a PR trigger, so it doesn't block the PR from being merged in

[yeikel]

We need a '0' exit code in case of a PR trigger, so it doesn't block the PR from being merged in

Can't we just make it an optional check?

[Haarolean]

We need a '0' exit code in case of a PR trigger, so it doesn't block the PR from being merged in

Can't we just make it an optional check?

not really, it's either all or none. And I've checked, if I use a 0 exit code it will be marked green, so no way to tell it has actually failed.

[yeikel]

We need a '0' exit code in case of a PR trigger, so it doesn't block the PR from being merged in

Can't we just make it an optional check?

not really, it's either all or none. And I've checked, if I use a 0 exit code it will be marked green, so no way to tell it has actually failed.

I don't understand? In Github, you can have optional checks and more so when this workflow is completely independent