Remove quality-queries input

[mbg]

We deprecated this short-lived, experimental input in CodeQL Action 3.30.2. This PR removes its remaining functionality and turns any use of it into an error.

Risk assessment

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

• High risk: Changes are not fully under feature flags, have limited visibility and/or cannot be tested outside of production.

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

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.
• Code Quality - The changes impact analyses when analysis-kinds: code-quality.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.
• Testing/None - This change does not impact any CodeQL workflows in production.

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.
  • Dashboards - I will watch relevant dashboards for issues after the release. Consider whether this requires this change to be released at a particular time rather than as part of a regular release.
  • 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]

Pull request overview

Removes the deprecated quality-queries input from the CodeQL init action and changes behavior so that any usage results in a configuration error.

Changes:

• Update getAnalysisKinds to throw ConfigurationError if quality-queries is provided.
• Remove quality-queries from init/action.yml inputs.
• Update unit tests and add a changelog entry documenting the removal.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/analyses.ts	Converts quality-queries handling from a warning/back-compat behavior to a hard error.
src/analyses.test.ts	Updates expectations to assert ConfigurationError is thrown when quality-queries is used.
lib/init-action.js	Generated JS output reflecting the TS changes.
init/action.yml	Removes the quality-queries input definition from the init action metadata.
CHANGELOG.md	Notes the removal of the experimental quality-queries input under UNRELEASED.

Comments suppressed due to low confidence (1)

src/analyses.ts:69

• getAnalysisKinds populates cachedAnalysisKinds before checking for the removed quality-queries input. If a first call hits the quality-queries error (e.g., the initial call in init-action.ts is caught/ignored), the cache remains set and subsequent calls will return early without re-checking quality-queries, effectively bypassing the intended hard error. Consider checking quality-queries before returning/setting the cache (and avoid mutating the cache when throwing), or always re-check quality-queries even when cached.

  if (!skipCache && cachedAnalysisKinds !== undefined) {
    return cachedAnalysisKinds;
  }

  cachedAnalysisKinds = await parseAnalysisKinds(

[Copilot]

Add a regression assertion that the quality-queries failure cannot be bypassed by caching (e.g., after the first throwsAsync, call getAnalysisKinds again with skipCache omitted/false and assert it still throws). This will catch cases where the cache is populated before throwing.