-
Notifications
You must be signed in to change notification settings - Fork 377
Make all errors on an unsupported platform ConfigurationError
s
#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
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
getCliConfigCategoryIfExists
was changed fromexport
to 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. |
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.
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.
@@ -265,7 +265,7 @@ export class CommandInvocationError extends Error { | |||
public args: string[], | |||
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.
* simply returns the original error. | ||
*/ | ||
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-errors
module 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