Skip to content

Overlay: check query packs for compatibility #2993

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

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

cklin
Copy link
Contributor

@cklin cklin commented Jul 25, 2025

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.

  • @alexet Please review the aspects concerning interaction with the CodeQL bundle
  • @mbg Please review all other aspects of the change

Merge / deployment checklist

  • Confirm this change is backwards compatible with existing workflows.
  • Confirm the readme has been updated if necessary.
  • Confirm the changelog has been updated if necessary.

@cklin cklin force-pushed the cklin/overlay-pack-check branch 4 times, most recently from 230fc32 to d0d4112 Compare July 29, 2025 18:58
@cklin cklin marked this pull request as ready for review July 29, 2025 19:20
@Copilot Copilot AI review requested due to automatic review settings July 29, 2025 19:20
@cklin cklin requested a review from a team as a code owner July 29, 2025 19:20
@cklin cklin requested review from mbg and alexet July 29, 2025 19:20
Copilot

This comment was marked as outdated.

Copy link
Contributor

@alexet alexet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@cklin
Copy link
Contributor Author

cklin commented Jul 31, 2025

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.

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.)

@cklin cklin marked this pull request as draft July 31, 2025 16:06
@cklin cklin force-pushed the cklin/overlay-pack-check branch from d0d4112 to f1a0360 Compare July 31, 2025 18:31
@cklin
Copy link
Contributor Author

cklin commented Jul 31, 2025

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.

I updated the PR to use this approach to identify the query packs to check for overlay compatibility. Related changes:

  • I removed the commit that adds resolvePacks() to the CodeQL interface
  • Instead, there is now a commit to add resolveQueriesStartingPacks()
  • To avoid confusion, I removed the unused resolveQueries() from CodeQL
  • While I am at it, I also removed the unused packDownload() from CodeQL

The other commits remain the same as before. PTAL.

@cklin cklin marked this pull request as ready for review July 31, 2025 20:38
@cklin cklin requested review from alexet and Copilot July 31, 2025 20:38
@cklin cklin force-pushed the cklin/overlay-pack-check branch from f1a0360 to 119d629 Compare August 5, 2025 18:03
Copilot

This comment was marked as outdated.

@cklin
Copy link
Contributor Author

cklin commented Aug 5, 2025

The latest force push updated CODEQL_OVERLAY_MINIMUM_VERSION to 2.22.3 at Alex's request.

Copy link
Member

@mbg mbg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As always, thanks for taking on this work! I have added a few suggestions, questions, and points for discussion.

const output = await runCli(cmd, codeqlArgs, { noStreamStdout: true });

try {
return JSON.parse(output) as string[];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Acknowledged. I will leave it to you to decide if and when you want to perform that overall cleanup.

src/init.ts Outdated
const qlpackPath = path.join(packDir, "qlpack.yml");
const qlpackContents = yaml.load(
fs.readFileSync(qlpackPath, "utf8"),
) as any;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


const packInfoFileContents = JSON.parse(
fs.readFileSync(packInfoPath, "utf8"),
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed with Copilot. It would be good to distinguish errors while reading/parsing JSON from other errors.

@@ -78,21 +78,40 @@ export async function runInit(
apiDetails: GitHubApiCombinedDetails,
logger: Logger,
): Promise<TracerConfig | undefined> {
fs.mkdirSync(config.dbLocation, { recursive: true });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noting this for future reference: it doesn't look like dbLocation is used by generateRegistries, so moving this seems fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@cklin cklin force-pushed the cklin/overlay-pack-check branch from 119d629 to 7ba8b26 Compare August 5, 2025 21:08
@Copilot Copilot AI review requested due to automatic review settings August 5, 2025 21:44
@cklin cklin force-pushed the cklin/overlay-pack-check branch from 7ba8b26 to 210aa6a Compare August 5, 2025 21:44
Copy link
Contributor

@Copilot Copilot AI left a 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 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.

  • Introduces a new checkPacksForOverlayCompatibility function that validates query pack overlay compatibility
  • Refactors the runInit function into runDatabaseInitCluster and updates the overlay compatibility checking workflow
  • Updates the minimum CodeQL overlay version requirement from "2.20.5" to "2.22.3"

Reviewed Changes

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
Comments suppressed due to low confidence (2)

src/init.ts:79

  • [nitpick] The parameter order in runDatabaseInitCluster is inconsistent with the original runInit function. Consider maintaining the same parameter order (codeql, config, sourceRoot, processName, then additional parameters) for better consistency and easier migration.
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

  • [nitpick] The interface QlPack is too generic and incomplete for representing a qlpack.yml file structure. Consider renaming it to QlPackMetadata or QlPackYaml to be more specific about its purpose.
interface QlPack {
  buildMetadata?: string;
}

@cklin
Copy link
Contributor Author

cklin commented Aug 5, 2025

I responded to some of the comments, and will follow up on the remaining ones tomorrow.

alexet
alexet previously approved these changes Aug 6, 2025
@cklin
Copy link
Contributor Author

cklin commented Aug 6, 2025

I responded to all comments (responses to copilot-initiated comments might be visible only under the original copilot reviews).

Also rebased the PR against current main to resolve merge conflicts.

@cklin cklin force-pushed the cklin/overlay-pack-check branch from 7a53966 to f5b3a08 Compare August 7, 2025 16:54
@cklin
Copy link
Contributor Author

cklin commented Aug 7, 2025

Another rebase to resolve merge conflicts.

@cklin cklin requested a review from mbg August 7, 2025 16:55
@cklin
Copy link
Contributor Author

cklin commented Aug 8, 2025

@mbg Friendly ping

Copy link
Member

@mbg mbg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


const packInfoFileContents = JSON.parse(
fs.readFileSync(packInfoPath, "utf8"),
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +788 to +799
cleanupDatabaseClusterDirectory(config, logger, {
disableExistingDirectoryWarning: true,
});
await runDatabaseInitCluster(
databaseInitEnvironment,
codeql,
config,
sourceRoot,
"Runner.Worker.exe",
qlconfigFile,
logger,
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a new PR check to exercise this re-initialization logic.

@cklin cklin force-pushed the cklin/overlay-pack-check branch from f5b3a08 to 37f26d0 Compare August 8, 2025 15:50
@cklin cklin force-pushed the cklin/overlay-pack-check branch 2 times, most recently from f17b8c2 to a81656b Compare August 8, 2025 16:50
@cklin cklin force-pushed the cklin/overlay-pack-check branch from a81656b to 2b2e27a Compare August 8, 2025 16:58
@cklin
Copy link
Contributor Author

cklin commented Aug 8, 2025

@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:

https://github.com/github/codeql-action/compare/37f26d0f026df3e20f15eb7bf68a3bb8d096418f..e47147711bab2cae6089f637baa13b51de265126

Edit: I updated the comparison link because I added a commit to support the codeql-pack.yml pack file name.

@cklin cklin requested a review from mbg August 8, 2025 17:13
@cklin cklin force-pushed the cklin/overlay-pack-check branch from 2b2e27a to e471477 Compare August 8, 2025 17:36
Copy link
Member

@mbg mbg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making those final changes!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants