Create wrapper runCliJson

[mario-campos]

Summary

A few of the CLI commands emit JSON. This PR creates a runCli wrapper function called runCliJson that expects JSON output from the CLI command. This change centralizes and reduces the number of JSON-parsing call sites in codeql.ts, making the code more readable and D.R.Y.er.

This PR is a prerequisite for #3950.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Workflow types:

• Advanced setup - Impacts users who have custom CodeQL workflows.
• Managed - Impacts users with dynamic workflows (Default Setup, Code Quality, ...).

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.
• Code Quality - The changes impact analyses when analysis-kinds: code-quality.
• Other first-party - The changes impact other first-party analyses.
• Third-party analyses - The changes affect the upload-sarif action.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).
• End-to-end tests - I am depending on PR checks (i.e. tests in pr-checks).

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.

How will you know if something goes wrong after this change is released?

• Telemetry - I rely on existing telemetry or have made changes to the telemetry.
  • Alerts - New or existing monitors will trip if something goes wrong with this change.

Are there any special considerations for merging or releasing this change?

• No special considerations - This change can be merged at any time.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.

[Copilot]

Warning

• Copilot's review of this pull request may be incomplete because some of the changed files are excluded by your Copilot content exclusion settings. See Excluding content from Copilot for details.

Pull request overview

This PR introduces a runCliJson helper in src/codeql.ts to standardize “run CLI command + parse JSON output” behavior, reducing duplicated JSON.parse logic across CodeQL CLI wrapper methods.

Changes:

• Add a generic runCliJson<T> wrapper around runCli that parses JSON output.
• Refactor several CodeQL wrapper methods (e.g., resolve languages, resolve build-environment, resolve queries, resolve database, version) to use runCliJson instead of inlined parsing.

Show a summary per file

File	Description
src/codeql.ts	Adds runCliJson and refactors multiple CLI wrapper methods to centralize JSON parsing.
lib/entry-points.js	Generated JS output update (content excluded from diff; also not generally reviewed for lib/).

Review details

Files excluded by content exclusion policy (1)

• lib/entry-points.js

• Files reviewed: 1/2 changed files
• Comments generated: 2
• Review effort level: Low

[mbg]

Could the --format=json or --format=betterjson argument be added automatically by runCliJson?

[mario-campos]

That would be nice! Unfortunately, there doesn't seem to be consistency between all of the calls of runCliJson:

• getVersion, resolveDatabase use --format=json
• resolveLanguages uses --format=betterjson
• resolveBuildEnvironment uses nothing??
• resolveQueriesStartingPacks uses --format=startingpacks

[mbg]

Elaborating on my comment on the other PR, what does this comment have to do with the changes here? Just a drive-by improvement?

[mario-campos]

what does this comment have to do with the changes here? Just a drive-by improvement?

Nothing, really—a "drive-by improvement" is a nice way to word it. But, it seemed more relevant here than in #3950. I'm fine to delete it, but I think it adds some value.

[mbg]

Thanks for addressing the feedback! I am slightly in two minds about 8ff2a75. On one hand, the type of runCliJson is more accurate now, but on the other hand, we still just assert the types (and that now makes the rest of the code uglier). If the intention is not to perform any validation on the JSON as part of this PR (which is OK, since that's the status quo) then the previous version where runCliJson returned Promise<T> was probably better.

[mario-campos]

If the intention is not to perform any validation on the JSON as part of this PR (which is OK, since that's the status quo) then the previous version where runCliJson returned Promise<T> was probably better.

Yes, attempting to validate the output—while justified and correct—is beyond the scope of this simple PR. I'll delete the commit.