Add a repository property for disabling overlay

[henrymercer]

Add a repository property that can be used to disable overlay for repositories that are owned by an organisation.

This means repositories that are owned by an organisation can disable overlay without needing to disable default setup too.

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.

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?

• Test repository - This change will be tested on a test repository before merging. (backlinked)
• 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.

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.
• Special considerations - This change should only be merged once certain preconditions are met. Please provide details of those or link to this PR from an internal issue.

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

Adds a new repository property that allows org-owned repositories to disable overlay analysis without disabling default setup, integrating this property into overlay mode selection and strengthening typing for repository properties.

Changes:

• Introduce github-codeql-disable-overlay repository property and parse repository properties into typed values (boolean/string).
• Update overlay database mode selection to honor the new property (with env var taking precedence).
• Add/adjust unit tests to cover new overlay selection behavior and updated API response typing.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/feature-flags/properties.ts	Adds new property name, typed property mapping/parsing, and updates API response typing.
src/feature-flags/properties.test.ts	Updates tests to align with the new exported API response type.
src/config-utils.ts	Threads repository properties into overlay mode computation and disables overlay when the property is set.
src/config-utils.test.ts	Adds tests verifying overlay is disabled/enabled based on the repository property and that env var precedence remains.
lib/init-action.js	Generated output updated to match TypeScript changes (not reviewed).

[Copilot]

The JSDoc still says the API returns a list of RepositoryProperty objects, but that type no longer exists and the response type is now GitHubRepositoryProperty[]/GitHubPropertiesResponse. Update the comment to match the actual types to avoid confusion for future maintainers.

Suggested change

	* The API returns a list of `RepositoryProperty` objects.
	* The API returns `GitHubPropertiesResponse`, a list of `GitHubRepositoryProperty` objects.

[Copilot]

isKnownPropertyName recomputes Object.values(RepositoryPropertyName) on every call, and it's called once per remote property in loadPropertiesFromApi. Consider using a module-level Set<string> of known names (or caching the array) so the per-property lookup is O(1) without repeated allocations.

Suggested change

	function isKnownPropertyName(value: string): value is RepositoryPropertyName {
	return Object.values(RepositoryPropertyName).includes(
	value as RepositoryPropertyName,
	);
	const KNOWN_REPOSITORY_PROPERTY_NAMES = new Set<string>(
	Object.values(RepositoryPropertyName),
	);
	function isKnownPropertyName(value: string): value is RepositoryPropertyName {
	return KNOWN_REPOSITORY_PROPERTY_NAMES.has(value);

[Copilot]

New behavior maps DISABLE_OVERLAY from the API string value to a boolean (value === "true"), but there is no unit test exercising this parsing/mapping in loadPropertiesFromApi. Add a test case that returns github-codeql-disable-overlay from the mocked API and asserts the resulting RepositoryProperties contains the correct boolean.

[mbg]

Looks good, glad to see this coming together! A bunch of minor points / questions, but nothing critical.

[mbg]

Minor: Since this is new, consider making this check case-insensitive?

[henrymercer]

This is consistent with other boolean checks, e.g. in environment variables. Also the repository properties UI has support for boolean properties, which will be set to either "true" or "false".

[mbg]

Agreed that it is consistent, but is it intuitive? Do we gain anything from being this strict here?

For the repo properties UI, doesn't that require each org to individually configure the property as a boolean? If so, it's easy to imagine someone accidentally configuring it as a string and then using True etc.

[henrymercer]

It's a valid point, but on the flip side if we allow True (or 1, etc) here, it's surprising when that isn't accepted elsewhere. We can make it clear in our instructions that this should be configured as a boolean property.

[mbg]

This seems good to merge. A couple of comments, but they aren't blocking.

[mbg]

I didn't comment on this in my initial review, but I quite like this mapping of properties to expected types and the associated machinery below.

[mbg]

Minor: We have this growing list of causes why overlay analysis is skipped/disabled, but presumably only one of these can be true at a given time. (At least based on the current logic, disabledByRepositoryProperty seems to imply skippedDueToCachedStatus is false.) Not blocking for this PR, but perhaps this should be refactored into an enum or similar that indicates the reason why overlay analysis was skipped/disabled. Otherwise, we might be mislead into thinking that e.g. skippedDueToCachedStatus would be true if we'd be skipping overlay analysis based on cache status, even if we already decided to disable it based on the repo property.

[henrymercer]

Yeah, great point, let's make this an enum.

[mbg]

(Similarly to my comment above, the way these diagnostics are emitted might suggest that all of these could be generated at the same time.)