-
Notifications
You must be signed in to change notification settings - Fork 428
Make all errors on an unsupported platform ConfigurationErrors
#3005
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
fc6dafd to
db0113a
Compare
henrymercer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks good! A couple of optional suggestions:
src/cli-errors.ts
Outdated
| [CliConfigErrorCategory.UnsupportedPlatform]: { | ||
| cliErrorMessageCandidates: [new RegExp("")], | ||
| precondition: isUnsupportedPlatform, | ||
| additionalErrorMessageToAppend: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use this in a few other error messages to give advice about how to fix the error, but I think in this case we might want to swap the ordering, e.g. something like
"This platform/arch combination (${process.platform}/${process.arch}) is not supported by the CodeQL CLI. See https://codeql.github.com/docs/codeql-overview/system-requirements. Underlying error: "
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense!
src/cli-errors.ts
Outdated
| if (configuration.precondition && !configuration.precondition()) { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A potentially simpler option could be modifying wrapCliConfigurationError directly (getCliConfigCategoryIfExists is only used there and can be made private). I don't have a strong opinion about it.
src/cli-errors.ts
Outdated
| cliErrorMessageCandidates: [new RegExp("")], | ||
| precondition: isUnsupportedPlatform, | ||
| additionalErrorMessageToAppend: | ||
| `This platform/arch combination (${process.platform}/${process.arch}) is not supported by the CodeQL CLI. See https://codeql.github.com/docs/codeql-overview/system-requirements`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: "arch" seems a bit odd in this otherwise fairly well formatted message. I'd spell it out as "architecture".
src/cli-errors.ts
Outdated
| [CliConfigErrorCategory.UnsupportedPlatform]: { | ||
| cliErrorMessageCandidates: [new RegExp("")], | ||
| precondition: isUnsupportedPlatform, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems quite hacky to me to use the cliErrorsConfig mechanism and depend on the order + a new check that works differently from the the existing ones (the existing ones are all logically OR-ed, while precondition is AND-ed).
I'd say that it would probably be better to handle this differently and insert a isUnsupportedPlatform check in wrapCliConfigurationError as @henrymercer suggests. I feel more strongly about this than him.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I was hesitating, you're making me lean towards that too
Tests were added with copilot, and uncovered a bug where one of the regexps looking for `[autobuild]` was not escaping the square brackets.
db0113a to
1cfc0c2
Compare
|
@henrymercer @mbg do you think this warrants a changelog entry? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR enhances error handling for the CodeQL Action by converting errors on unsupported platforms to ConfigurationErrors and improving the regular expression pattern matching. The changes ensure that CLI errors on unsupported platform/architecture combinations are properly categorized as configuration errors while maintaining backward compatibility for existing workflows.
Key Changes
- Added unsupported platform detection that returns ConfigurationError with helpful messaging
- Fixed regex pattern for Gradle build failures by properly escaping square brackets
- Added comprehensive test coverage for the cli-errors module
Reviewed Changes
Copilot reviewed 4 out of 6 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/cli-errors.ts | Enhanced error handling with unsupported platform detection and fixed regex escaping |
| src/cli-errors.test.ts | Added comprehensive test suite covering all CLI error scenarios and edge cases |
| lib/cli-errors.js | Generated JavaScript code reflecting the TypeScript changes |
| lib/cli-errors.test.js | Generated JavaScript test file |
Comments suppressed due to low confidence (2)
src/cli-errors.ts:322
- There's a typo in the comment: 'reutrn' should be 'return'.
* the underlying `cliError`. Otherwise, reutrn `undefined`.
src/cli-errors.ts:297
- The function
getCliConfigCategoryIfExistswas changed fromexportto private visibility without being marked as deprecated first. This is a breaking change that could affect consumers of this module.
function getCliConfigCategoryIfExists(
|
@redsun82 I don't think a changelog entry is needed for this, since it shouldn't have any user-facing effects. |
mbg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making some changes and letting Copilot generate some tests. I have a few thoughts on the new version of this.
As already mentioned above, I don't think a changelog entry will be necessary, since we are just changing an error type and that doesn't affect users.
src/cli-errors.ts
Outdated
| return new ConfigurationError( | ||
| "The CodeQL CLI does not support the platform/architecture combination of " + | ||
| `${process.platform}/${process.arch} ` + | ||
| "(see https://codeql.github.com/docs/codeql-overview/system-requirements). " + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: Should we add this to the DocUrl enum?
src/cli-errors.ts
Outdated
| ![ | ||
| ["linux", "x64"], | ||
| ["win32", "x64"], | ||
| ["darwin", "x64"], | ||
| ["darwin", "arm64"], | ||
| ].some( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: It might be nicer if this array was a top-level constant, rather than inlined here.
src/cli-errors.ts
Outdated
| const unsupportedPlatformError = getUnsupportedPlatformError(cliError); | ||
| if (unsupportedPlatformError !== undefined) { | ||
| return unsupportedPlatformError; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a bit like an improvised try/catch block. Why not just return a bool from a function that checks if the platform is supported and then throw the error here?
src/cli-errors.test.ts
Outdated
| function createCommandInvocationError( | ||
| cmd: string, | ||
| args: string[], | ||
| exitCode: number | undefined, | ||
| stderr: string, | ||
| stdout: string = "", | ||
| ): CommandInvocationError { | ||
| return new CommandInvocationError(cmd, args, exitCode, stderr, stdout); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: This seems a bit unnecessary given it's more or less the same as CommandInvocationError
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
copilot's reasoning here was adding the default stdout value I think. I added that to the constructor directly
src/cli-errors.test.ts
Outdated
| Object.defineProperty(process, "platform", { value: "unsupported" }); | ||
| Object.defineProperty(process, "arch", { value: "unsupported" }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we'd normally use sinon to stub a function which returns what we want for a test. I can't find any existing uses of Object.defineProperty in our codebase.
mbg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This looks good to me now. I added one minor comment, but feel free to ignore that.
| public exitCode: number | undefined, | ||
| public stderr: string, | ||
| public stdout: string, | ||
| public stdout: string = "", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I don't actually see stdout being used here, only stderr, so this shouldn't break anything.
| */ | ||
| export function wrapCliConfigurationError(cliError: CliError): Error { | ||
| if (isUnsupportedPlatform()) { | ||
| return getUnsupportedPlatformError(cliError); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: The getUnsupportedPlatformError function is probably not necessary and this could have been inlined here, but I don't feel strongly about it. Definitely not blocking for me.
When running on an an unsupported platform, raise a ConfigurationError, but only if the CLI chokes on something. This leaves existing action configurations running on unsupported platforms but succeeding in the same state, but on the other hand avoids us getting flagged by errors happening in those unsupported cases.
Also, tests were added for the whole
cli-errorsmodule with help from copilot. Incidentally, this uncovered a bug where one of the regexps was not escaping square brackets while searching for[autobuild]. This bug is now fixed.Merge / deployment checklist