fix(github): Ignore vulnerability alerts in FIXED or DISMISSED states

[nyg]

Changes

When querying Github's GraphQL API to retrieve vulnerability alerts, only retrieve those that are in OPEN state.

Context

Closes #14316

The GraphQL request to retrieve vulnerabilities currently ignores their state (OPEN, FIXED or DISMISSED).

Fixed or dismissed vulnerabilities should not be considered as renovate will try to create PRs for these vulnerabilities, when actually the dependencies are already fixed (or the owner has decided they should not be fixed). This will also propose the PRs in the Dashboard issue under "Other branches" or "Ignored or blocked".

It seems this state was added recently, which may explain why this issue was not noticed before.

https://docs.github.com/en/graphql/reference/enums#repositoryvulnerabilityalertstate
https://docs.github.com/en/graphql/overview/changelog (Enum added on Feb 16th, 2022)

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please tick one)

Note: I have not written any test for this as this is a feature of Github's GraphQL API. Let me know if I should still be writing a test for it.

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[viceice]

This will potentially break GHE and needs tests.

[rarkins]

If it's too complicated to add GHE version detection to this, it would be better to undo this change and add the appropriate filtering on our client side instead, so it works with all.

[viceice]

We already know if we on GHE, so check should be easy. We can enable filter on GHE when we know on which GHE version it's available later.

[rarkins]

But the problem this is addressing will still exist on GHE in the meantime?

[nyg]

If it's too complicated to add GHE version detection to this, it would be better to undo this change and add the appropriate filtering on our client side instead, so it works with all.

Indeed, I think it would be a bit complicated to check for the GHE versions that support of not the new state field.

But then, how would you filter on the client side? Because if we add the state field to the query, then it's also going to fail with the GHE versions that don't support it.

One option I thought about, but don't know if it's doable, is schema introspection, i.e. to check if the state field is present or not, and depending on the result include or not the state field in the query.

But the problem this is addressing will still exist on GHE in the meantime?

From what I understand, yes.

[rarkins]

Reopening this, as I changed my mind :)

[viceice]

Otherwise LGTM

[viceice]

Needs snapshot update

[renovate-release]

🎉 This PR is included in version 32.9.0 🎉

The release is available on:

• GitHub release
• 32.9.0

Your semantic-release bot 📦🚀

[renovate-release]

🎉 This issue has been resolved in version 32.76.3 🎉

The release is available on:

• GitHub release
• 32.76.3

Your semantic-release bot 📦🚀