-
Notifications
You must be signed in to change notification settings - Fork 334
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
Add logging statements declaring state of the cli_config_file_enabled #1281
Conversation
src/analyze.ts
Outdated
|
||
if (await util.useCodeScanningConfigInCli(codeql, featureFlags)) { | ||
logger.info( | ||
"Code Scanning configuration file being processed in the codeql-action." |
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.
Wrong way round!
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.
Arrrgh!
It's possible to determine this otherwise, but this makes it easier to spot.
f8605b9
to
6ace05b
Compare
Oh...need to change how the query filters tests work. Some of them are explicitly expecting the config to be processed by the action and others the CLI. I will need to change how the env var is working for them. Edit: Hmmm...the error message is a little more worrying. Maybe there's something really wrong here. |
The user config parser in the CLI doesn't yet support it.
1861036
to
59fbe34
Compare
src/util.ts
Outdated
@@ -817,6 +817,22 @@ export async function useCodeScanningConfigInCli( | |||
return await codeQlVersionAbove(codeql, CODEQL_VERSION_CONFIG_FILES); | |||
} | |||
|
|||
export async function logCodeScanningConfgInCli( |
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 typo in name.
b73c507
to
5960ce1
Compare
await logCodeScanningConfigInCli(codeQL, featureFlags, logger); | ||
|
||
if (!(await useCodeScanningConfigInCli(codeQL, featureFlags))) { |
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 will hit the feature flags endpoint twice right? (And I think we don't attempt to add cache parameters to the API requests.) Can we make it call only once? Not sure of the cleanest way; perhaps the logCodeScanningConfigInCli
function should just accept the boolean result of the use
function, without calling use
.
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.
Hmmm...you're right. Feature flags values are not being cached. Rather than implementing a workaround for useCodeScanningConfigInCli
only, I think it makes more sense to simply add the caching (it's not too much code).
What do you think about my doing this in a separate PR?
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.
Wait!!!! It's a little bit hidden, but the response is cached: https://github.com/aeisenberg/codeql-action/blob/5960ce11900cc253a1ac219eb7cd41769b00cebf/src/feature-flags.ts#L98-L99
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.
Oh fancy! Nothing to worry about then.
Minor change to insert a log statement to keep track of the new feature flag. It's possible to determine this otherwise, but this makes it easier to spot.
Also, Avoid using single value as array
The user config parser in the CLI doesn't yet support it.