Abort CodeQL action if the status cannot be reported #308
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
simon-engledew
force-pushed
the
simon-engledew/fast-fail
branch
from
1baea41 to
0c3bc82
Compare
Put more fine grained logic around which errors we ignore and process. Re-instate status reporting in Enterprise. Abort the code scanning process the status endpoint reports it is not configured.
simon-engledew
force-pushed
the
simon-engledew/fast-fail
branch
from
2ca8035 to
68dedea
Compare
Author
|
@robertbrignull I had a chat with Marco and he is keen to keep using the status endpoint to determine if code scanning is enabled. To do so, I have had to undo your previous change and start treating 404 and 403 as stop conditions. I have attempted to keep to the spirit of the original code by treating other errors in a similar way:
Unstitching something makes me nervous. I would be very grateful if you could give this a once over and see if it makes sense! ❤️ |
Contributor
robertbrignull
left a comment
robertbrignull
left a comment
There was a problem hiding this comment.
Generally looks good and looks like it should work, though I had a few comments.
simon-engledew
force-pushed
the
simon-engledew/fast-fail
branch
from
e151951 to
0a6fcd8
Compare
simon-engledew
force-pushed
the
simon-engledew/fast-fail
branch
from
0a6fcd8 to
f3ff4c8
Compare
Until there is a more robust versioning system it is probably safest to require endpoint compatiblity and not continue the action if there is a mismatch.
simon-engledew
force-pushed
the
simon-engledew/fast-fail
branch
from
fa1125c to
17d4671
Compare
robertbrignull
approved these changes
Nov 19, 2020
Contributor
robertbrignull
left a comment
robertbrignull
left a comment
There was a problem hiding this comment.
Thanks. The changes LGTM now, and I've tried it out on a GHES instance and it works as expected.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Save action minutes by only running the CodeQL check if code scanning is enabled for the repository.
This reverts some work done in #128
This is nearly a no-op against Enterprise but there is value in not maintaining two separate behaviours.
Enterprise will log a warning and not fail on a 422. This may occur if the bundled version of CodeQL was updated on an old version of Enterprise.Merge / deployment checklist
@robertbrignullif this behaviour is new, or if there is an edge case that I have not managed to reproduce in my local setup.I think this is likely a change in octokit. As both the response and the HTTP error have a status field it seems reasonable to check it on both success and failure using the same code. If it changes in future this code should continue to work the same.