Use the combined bundle when queries may need other languages' library packs by henrymercer · Pull Request #4184 · github/codeql-action

henrymercer · 2026-09-30T18:35:34Z

We support custom configuration files that include packs for other languages, for example:

name: Use custom queries
disable-default-queries: true
queries:
  ...
  - name: Go queries
    uses: codeql-testing/go-querypack@master
  - name: Cpp queries
    uses: codeql-testing/cpp-querypack@second-branch
  - name: JavaScript queries
    uses: codeql-testing/javascript-querypack/show_ifs2.ql@master
  - name: Python queries
    uses: codeql-testing/python-querypack/show_ifs2.ql@second-branch

as taken from our PR checks.

If these custom queries live in compiled packs, then the packs ship their own dependencies. However if the custom query is just a path to a QL file, then the dependencies are resolved from a bundle.

This creates an issue with per-language bundles: CodeQL resolves every configured query before selecting the ones for the analyzed language, so a single-language analysis with a configuration like the above will fail. This is evidenced by failures in the "Go: Custom queries" and "Start proxy" PR checks when using per-language bundles.

This PR only selects a per-language bundle when the query configuration known before CodeQL is set up can't reference such queries: there's no configuration file, the config input is unset or we're in a dynamic workflow such as default setup, and the queries input and github-codeql-extra-queries repository property only name built-in query suites. This avoids loading the configuration before setting up CodeQL, at the cost of using the combined bundle for configuration files that only use built-in queries.

This PR also modifies setup-codeql to always use the combined bundle, since it can't tell whether the queries that a workflow runs with the CLI will need library packs for other languages. A separate commit corrects the docs for its languages and analysis-kinds inputs, which said to also pass them to init, even though init fails if setup-codeql has run in the same job.

It also disables per-language bundles in the "Export file baseline information" PR check, since a per-language bundle only reports file baseline information for its own language. The second commit moves defaultSuites so that per-language-bundles.ts can use it without an import cycle.

Finally, it moves per-language bundles to a new per_language_bundles_v2 feature flag, so that we can roll them out to Action versions that include this fix without also enabling them for earlier versions.

Risk assessment

Low risk: The change only affects bundle selection when the per_language_bundles or per_language_bundles_v2 feature flag is enabled.

Which use cases does this change impact?

Workflow types:

Advanced setup - Single-language analyses with a configuration file, a config input, or queries that aren't built-in query suites, and workflows that pass a single language to setup-codeql.
Managed - Default setup analyses that get a configuration file, or queries that aren't built-in query suites, from repository properties.

Products:

Code Scanning
Code Quality

Environments:

Dotcom - Per-language bundles are only selected on GitHub.com.

How did/will you validate this change?

Unit tests - Each source of query configuration, and bundle selection for releases and nightlies. The setup-codeql Action's entry point has no unit tests, so its reason is only covered indirectly.
End-to-end tests - "Go: Custom queries" and "Start proxy" use configuration files that reference other languages' queries, so they cover this change whenever they download a bundle with per-language bundles enabled.

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

Feature flags - Disable per-language bundle selection with per_language_bundles_v2.

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

Telemetry - Monitor init failures in analyses that use a per-language bundle.

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.

Co-authored-by: Copilot App <[email protected]>

…rary packs Co-authored-by: Copilot App <[email protected]>

Co-authored-by: Copilot App <[email protected]>

…p-codeql` Co-authored-by: Copilot App <[email protected]>

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.

Copilot review overview

🟢 Approval recommended

Bundle eligibility is consistently propagated and covered by focused tests without unresolved correctness issues.

Review effort: Balanced
Findings: None

What changed in this PR

Updates bundle selection to use combined bundles whenever configured queries may depend on other languages’ library packs.

Changes:

Detects query configurations requiring combined bundles.
Propagates bundle-selection reasoning through CodeQL setup.
Updates tests, documentation, and PR-check configuration.

File	Description
`src/per-language-bundles.ts`	Adds query eligibility logic.
`src/per-language-bundles.test.ts`	Tests eligibility and explanations.
`src/setup-codeql.ts`	Applies eligibility to release and nightly bundles.
`src/setup-codeql.test.ts`	Tests combined-bundle selection.
`src/setup-codeql-action.ts`	Forces combined bundles for standalone setup.
`src/init-action.ts`	Collects query configuration inputs.
`src/init.ts`	Propagates bundle-selection reasoning.
`src/codeql.ts`	Propagates setup options.
`src/codeql.test.ts`	Updates setup calls.
`src/upload-lib.ts`	Updates initialization call.
`src/config/db-config.ts`	Centralizes built-in suite names.
`src/analyze.ts`	Uses centralized suite names.
`src/analyze.test.ts`	Updates suite import.
`setup-codeql/action.yml`	Corrects input documentation.
`pr-checks/checks/export-file-baseline-information.yml`	Disables per-language bundles for the baseline check.
`lib/entry-points.js`	Generated output; excluded from review.
`.github/workflows/__export-file-baseline-information.yml`	Generated workflow; excluded from review.

Files excluded by content exclusion policy (2)

.github/workflows/__export-file-baseline-information.yml
lib/entry-points.js

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Co-authored-by: Copilot App <[email protected]>

mbg

Thank you for taking care of this! I think this approach makes sense to work around the issue. Query customisation is reasonably rare so that this still allows most users to benefit from per-language bundles, while avoiding any issues like we saw in CI for those that do customise them.

I left a few comments, with one or two points about long-term maintainability and otherwise minor comments. So, generally this looks pretty good already and it shouldn't be far off from being ready to merge.

mbg · 2026-10-01T11:39:34Z

  CODEQL_ACTION_SKIP_FILE_COVERAGE_ON_PRS: false
  CODEQL_ACTION_SUBLANGUAGE_FILE_COVERAGE: true
+  # Per-language bundles only report file baseline information for their own language.
+  CODEQL_ACTION_PER_LANGUAGE_BUNDLES: false


Question: Rather than disabling per-language bundles here, would it make sense to analyse all languages (at once or in a matrix) if checking that the notification is produced for all supported languages is the primary goal of this test? (Perhaps we could add this check on to another workflow if we want to avoid this taking to longer to run / spawning more jobs.)

Alternatively, if checking this for all languages isn't essential, then we could just simplify the check and continue to allow per-language bundles.

Those are all valid approaches too, but I think the current check is a good balance between separation of concerns (separate check for separate test), speed (just extracting and running queries against one language), and coverage (checking each language's baseline information).

mbg · 2026-10-01T11:40:40Z

      gitHubVersion.type,
      codeQLDefaultVersionInfo,
      rawLanguages,
+      undefined, // otherLanguagePacksReason: this Action doesn't take a query configuration


Minor: Prefer placing the comment above the relevant line, rather than at the end of it.

I feel the other way — I'll leave this as is, but open to discussing this in general and updating the linter configuration.

mbg · 2026-10-01T11:46:58Z

+ */
+export function getOtherLanguagePacksReason(
+  inputs: QueryConfigInputs,
+): string | undefined {


Minor: Consider creating an enum for the reasons, returning a value of that enum here, and then mapping to a string when needed.

I can see some value in listing all the reasons, but since we also have values associated with the reasons (e.g. the config file path), I don't listing the reasons is worth the complexity.

mbg · 2026-10-01T11:48:20Z

+  // We assume that dynamic workflows, which GitHub manages, don't use the `config` input to add
+  // queries. For example, default setup only uses it for threat models and model packs.


Minor: Add a sentence before this that config can contain the same custom query configuration as config-file, except in Default Setup, where we manage it and know that there isn't such a query config.

mbg · 2026-10-01T11:50:15Z

+  if (inputs.configInput !== undefined && !inputs.isDynamicWorkflow) {
+    return "the 'config' input may use queries that need library packs for other languages";
+  }


Long-term issue: if our hard-coded assumption about dynamic workflows ever changes in any of the products that use dynamic workflows, then this will be quite tricky to track down. Perhaps to guard a little again that and be extra defensive, consider introducing a constant somewhere along the lines of ASSUME_DEFAULT_SETUP_CONFIG_NO_QUERIES with a suitable comment and factor that into the logic here.

Are you thinking of adding an environment variable to the default setup template as an indicator of when we can no longer assume that the default setup config won't specify custom queries? Perhaps it would be simpler to indeed parse the config input and check that it only has the properties we expect?

mbg · 2026-10-01T11:51:55Z

+      ?.trim()
+      // A leading '+' combines these queries with those configured elsewhere.
+      .replace(/^\+/, "")
+      .split(",")


I'd expect that we already have this logic elsewhere in the codebase. Rather than re-implementing it here, use the existing implementation. Refactor it out of its current location if needed to make it shareable.

mbg · 2026-10-01T11:54:13Z

+  if (otherLanguagePacksReason !== undefined) {
+    return explain(otherLanguagePacksReason);
+  }


Minor: Add a comment above this along the lines of "If otherLanguagePacksReason is defined, we have determined that query customisation may require multiple language packs".

mbg · 2026-10-01T11:55:55Z

+      configInput: getOptionalInput("config"),
+      queriesInput: getOptionalInput("queries"),


Minor: Refactor these getOptionalInput calls out so that the results can be re-used without needing to call getOptionalInput again below.

henrymercer and others added 5 commits September 29, 2026 19:31

Disable per-language bundles in the file baseline PR check

b5a476b

Co-authored-by: Copilot App <[email protected]>

Move defaultSuites to config/db-config.ts

5e3132d

Co-authored-by: Copilot App <[email protected]>

Avoid per-language bundles when queries may need other languages' lib…

1609a51

…rary packs Co-authored-by: Copilot App <[email protected]>

Always use the combined bundle in setup-codeql

d8b6f2a

Co-authored-by: Copilot App <[email protected]>

Fix the docs for the languages and analysis-kinds inputs of `setu…

7816c33

…p-codeql` Co-authored-by: Copilot App <[email protected]>

github-actions Bot added the size/L May be hard to review label Sep 30, 2026

henrymercer requested a balanced review from Copilot October 1, 2026 09:17

Copilot started reviewing on behalf of henrymercer October 1, 2026 09:18 View session

Copilot AI reviewed Oct 1, 2026

View reviewed changes

henrymercer and others added 2 commits October 1, 2026 11:48

Use a new feature flag for per-language bundles

87a1923

Co-authored-by: Copilot App <[email protected]>

Omit the feature flag name from the per-language bundle debug log

2da0d29

Co-authored-by: Copilot App <[email protected]>

henrymercer marked this pull request as ready for review October 1, 2026 11:32

henrymercer requested a review from a team as a code owner October 1, 2026 11:32

mbg reviewed Oct 1, 2026

View reviewed changes

		// We assume that dynamic workflows, which GitHub manages, don't use the `config` input to add
		// queries. For example, default setup only uses it for threat models and model packs.

		configInput: getOptionalInput("config"),
		queriesInput: getOptionalInput("queries"),

Conversation

henrymercer commented Sep 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Risk assessment

Which use cases does this change impact?

How did/will you validate this change?

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

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

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

Merge / deployment checklist

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot review overview

🟢 Approval recommended

Uh oh!

mbg left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

henrymercer commented Sep 30, 2026 •

edited

Loading