Re-enable waiting for processing by default, using the new API semantics.

[chrisgavin]

This re-enables waiting for processing by default, after some changes to the API which will allow it to work on pull requests from forks.

It also makes it more tolerant of errors returned by the API, since waiting for processing is not essential.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[edoardopirovano]

Would you mind if we hold this until next week when we've fixed the SHA of codeql-action that goes into GHES 3.5?

[edoardopirovano]

A thought I had just after approving: There was previously an issue with the API end-point that has now been fixed, right? But does that mean this could cause problems for users on old versions of GHES who pull in a new version of the Action? Should we gate this to only work on dot com or on new versions of GHES?

[edoardopirovano]

I appreciate the switch to a warning means we won't fail, but it would still be nice to avoid warnings in the log.

[chrisgavin]

So you will still get a warning on old GHES versions, that is true. When I was implementing this it seemed somewhat reasonable to me, because it is indeed true that we cannot tell you if your analysis processing will fail.

I can add a check for the GHES version if you think this is not the best behavior though.

[edoardopirovano]

Hmm, I guess it's fine to have a warning in the logs in the fairly rare case of a pull request from a fork in a GHES instance. Or at least, it's probably not worth the extra complexity of having version checks in the code. Let's leave this as-is.