| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
It doesn't feel to me that resolve packs is quite the right command (although it looks like it will work).It feels like we should run resolve queries with --format startingpacks to find the query packs we care about, and then just use those.
But I am also not fully sure of all the subtleties of either choice.
Sorry, something went wrong.
Thanks for the suggestion! When I first looked into the problem, I considered this approach but was unable to get it to work. While codeql resolve queries with --format startingpacks can map queries to their containing query packs, there does not seem to be a way to get the list of queries that would be used in the analysis and feed that into codeql resolve queries. I could see that codeql database init already computes that information (though a deep-plumbing subcommand) for internal use, but no easy way to obtain that information from outside the CodeQL CLI. Re-interpreting the Code Scanning config file in the action seems like a lot of work for relatively little gain. Prompted by your suggestion, I looked again. This time I noticed that codeql database init actually generates config-queries.qls suite file with the list of queries, so all I need to do is to feed that suite file into codeql resolve queries, and I can get the list of query packs to check for overlay compatibility. (There is the slight complication that codeql resolve queries --format startingpacks would also return query packs that have not been compiled. I will have to make the action ignore those query packs when checking for overlay compatibility.) |
Sorry, something went wrong.
I updated the PR to use this approach to identify the query packs to check for overlay compatibility. Related changes:
The other commits remain the same as before. PTAL. |
Sorry, something went wrong.
|
The latest force push updated CODEQL_OVERLAY_MINIMUM_VERSION to 2.22.3 at Alex's request. |
Sorry, something went wrong.
There was a problem hiding this comment.
As always, thanks for taking on this work! I have added a few suggestions, questions, and points for discussion.
Sorry, something went wrong.
| const output = await runCli(cmd, codeqlArgs, { noStreamStdout: true }); | ||
|
|
||
| try { | ||
| return JSON.parse(output) as string[]; |
There was a problem hiding this comment.
Not specific to this PR: I see that we follow the same JSON.parse(output) as type pattern throughout the implementation here, but that doesn't actually give us any guarantees that the result of JSON.parse is compatible with the type here. This may effectively delay an error until a later point. Where possible, we should probably check that the result actually what we expect (and not just valid JSON) as done in e.g. #2956.
I don't think this has to be addressed here, but we might want to look into improving this throughout in the future.
Sorry, something went wrong.
There was a problem hiding this comment.
Acknowledged. I will leave it to you to decide if and when you want to perform that overall cleanup.
Sorry, something went wrong.
| const qlpackPath = path.join(packDir, "qlpack.yml"); | ||
| const qlpackContents = yaml.load( | ||
| fs.readFileSync(qlpackPath, "utf8"), | ||
| ) as any; |
There was a problem hiding this comment.
I agree with Copilot here - it would be good to have typings for (at least) the parts of the format that are used here.
This might also make the tests a little nicer since you can then have test objects of this type that you can serialise, rather than hard-coded strings.
Sorry, something went wrong.
|
|
||
| const packInfoFileContents = JSON.parse( | ||
| fs.readFileSync(packInfoPath, "utf8"), | ||
| ); |
There was a problem hiding this comment.
Agreed with Copilot. It would be good to distinguish errors while reading/parsing JSON from other errors.
Sorry, something went wrong.
| apiDetails: GitHubApiCombinedDetails, | ||
| logger: Logger, | ||
| ): Promise<TracerConfig | undefined> { | ||
| fs.mkdirSync(config.dbLocation, { recursive: true }); |
There was a problem hiding this comment.
Just noting this for future reference: it doesn't look like dbLocation is used by generateRegistries, so moving this seems fine.
Sorry, something went wrong.
There was a problem hiding this comment.
Furthermore, codeql database init generally expects the database path to be non-existent and reports an error when the database path already exists. (There are some exceptions, such as when initializing an overlay database.) So I would be very surprised if generateRegistries() writes anything into dbLocation.
Sorry, something went wrong.
There was a problem hiding this comment.
This PR adds query pack compatibility checking for overlay analysis in the CodeQL Action. The main purpose is to ensure that when overlay analysis is enabled, all query packs involved are compatible with the installed CodeQL CLI's overlay analysis support before proceeding.
Copilot reviewed 20 out of 29 changed files in this pull request and generated 2 comments.
Show a summary per file| File | Description |
|---|---|
| src/util.ts | Adds getGeneratedSuitePath helper function for query suite paths |
| src/testing-utils.ts | Updates mock functions to support overlayVersion parameter |
| src/overlay-database-utils.ts | Updates minimum CodeQL overlay version constant |
| src/init.ts | Adds overlay compatibility checking logic and refactors database initialization |
| src/init.test.ts | Adds comprehensive tests for overlay compatibility checking |
| src/init-action.ts | Updates main initialization flow to handle overlay compatibility checks |
| src/config-utils.test.ts | Updates test configuration to use new minimum overlay version |
| src/codeql.ts | Adds overlayVersion to VersionInfo and resolveQueriesStartingPacks method |
| src/analyze.ts | Uses new getGeneratedSuitePath helper function |
| src/analyze.test.ts | Removes unused packDownload mock |
src/init.ts:79
export async function runDatabaseInitCluster(
databaseInitEnvironment: Record<string, string | undefined>,
codeql: CodeQL,
config: configUtils.Config,
sourceRoot: string,
processName: string | undefined,
qlconfigFile: string | undefined,
logger: Logger,
): Promise<void> {
src/init.ts:138
interface QlPack {
buildMetadata?: string;
}
Sorry, something went wrong.
|
I responded to some of the comments, and will follow up on the remaining ones tomorrow. |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for addressing my feedback from the last review, and sorry it took longer than I'd like to re-review.
This continues to look good, thank you! I've followed up to a few of your responses and added a couple of suggestions for potential improvements on test coverage.
I am generally happy with this and there isn't anything that's really blocking. Have a look over the comments and see if you want to change anything in light of them. I will be happy to approve this after you've had a look.
Sorry, something went wrong.
|
|
||
| const packInfoFileContents = JSON.parse( | ||
| fs.readFileSync(packInfoPath, "utf8"), | ||
| ); |
There was a problem hiding this comment.
On second thought, I think it's probably fine. You're right that whatever errors come out of here are probably distinguishable based on the result of util.getErrorMessage(e) in the existing catch block.
Sorry, something went wrong.
There was a problem hiding this comment.
The PR removes resolveQueries and adds resolveQueriesStartingPacks. For the corresponding tests, the ones for resolveQueries are removed, but none are added for resolveQueriesStartingPacks. Do you think it would make sense to add some?
Sorry, something went wrong.
There was a problem hiding this comment.
I did not remove any resolveQueries tests. What I removed was unnecessary resolveQueries and packDownload stubs in config loading tests. Those tests are still working the same way they used to: the removed resolveQueries and packDownload stubs has no effect on the tests because the tested code does not call either of those functions.
resolveQueriesStartingPacks is just a wrapper that calls the corresponding CodeQL CLI subcommand, and I don't think tests for that function would add much value.
Sorry, something went wrong.
| cleanupDatabaseClusterDirectory(config, logger, { | ||
| disableExistingDirectoryWarning: true, | ||
| }); | ||
| await runDatabaseInitCluster( | ||
| databaseInitEnvironment, | ||
| codeql, | ||
| config, | ||
| sourceRoot, | ||
| "Runner.Worker.exe", | ||
| qlconfigFile, | ||
| logger, | ||
| ); |
There was a problem hiding this comment.
Do you think it's worth adding a test that exercises this logic? I don't see anything wrong with things as they are, but it might be worthwhile to have to check that we don't break this sequence, especially since an error in cleanupDatabaseClusterDirectory would be fatal. I don't feel strongly about it.
Sorry, something went wrong.
There was a problem hiding this comment.
I added a new PR check to exercise this re-initialization logic.
Sorry, something went wrong.
This commit inlines runInit(), so that it is easier to repeat the runDatabaseInitCluster() call when needed.
|
@mbg Thanks for your comments. I think I responded to them all. There has been a few force pushes to the PR branch, both to resolve merge conflicts and to iterate on the new database re-init PR check. The following link contains all the relevant changes since your last review: Edit: I updated the comparison link because I added a commit to support the codeql-pack.yml pack file name. |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for making those final changes!
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This PR updates the init action to prevent overlay analysis (or overlay-base database construction) when one of the query packs involved does not support overlay analysis with the installed CodeQL CLI.
Merge / deployment checklist