Add github-codeql-tools repository property for tools input

[Copilot]

Large organizations downloading a pinned CodeQL CLI version on every analysis run can hit rate limits. This adds a github-codeql-tools repository property that lets org admins set the tools source at org level, avoiding per-run downloads.

What changes

New repository property: github-codeql-tools

• Org admins can set this on their repositories (e.g., github-codeql-tools: toolcache)
• When set, it acts as a default tools input — explicit workflow-level tools input always takes precedence
• toolcache value works without requiring the AllowToolcacheInput feature flag or a dynamic workflow trigger, since the org admin is explicitly opting in

Implementation

• Added RepositoryPropertyName.TOOLS = "github-codeql-tools" to the existing property enum/type system in src/feature-flags/properties.ts
• Threaded a toolsInputFromRepositoryProperty flag through the call chain: initCodeQL → setupCodeQL → setupCodeQLBundle → getCodeQLSource
• In getCodeQLSource, toolcache with this flag set bypasses the feature-flag/dynamic-workflow guard and emits distinct log messages referencing the repository property name rather than tools: toolcache
• init-action.ts resolves the effective tools input: workflow input wins; property is used only when no explicit input is given

Risk assessment

High risk: Not fully under a feature flag — the new code path activates when the repository property is set.

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.

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

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.

The repository property must be explicitly set by an org admin; no existing workflows are affected unless they set github-codeql-tools.

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.

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.

---

⌨️ Start Copilot coding agent tasks without leaving your editor — available in VS Code, Visual Studio, JetBrains IDEs and Eclipse.