Tolerate errors loading repository properties

[henrymercer]

Repository properties can be used to configure the analysis. Therefore in general we probably don't want to tolerate errors loading repository properties, because this could mean that we run a different set of queries to what was requested, for instance.

However in the first stages of the rollout, tolerate errors.

Also, don't attempt to load repository properties for repositories owned by users, as these cannot have custom properties.

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

Products:

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

Environments:

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

How did/will you validate this change?

• Test repository - This change will be tested on a test repository before merging.

I've tested it on this repository, and will run another test on a repo owned by a user.

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

• Feature flags - All new or changed code paths can be fully disabled with corresponding feature flags.

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]

Pull request overview

This PR introduces error tolerance for loading repository properties during the initial rollout phase. The change adds a Result type for better error handling, skips property loading for user-owned repositories (which cannot have custom properties), and logs diagnostic telemetry when property loading fails instead of causing the workflow to fail.

Changes:

• Introduced a generic Result<T, E> type for error handling
• Added loadRepositoryProperties helper function that tolerates errors during property loading
• Skips repository property loading for user-owned repositories
• Improved logging when no repository properties are found

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/util.ts	Adds a new Result class for functional error handling with ok/error states
src/init-action.ts	Refactors property loading into a separate function with error tolerance and adds diagnostic telemetry for failures
src/feature-flags/properties.ts	Improves logging to distinguish between no properties found vs properties loaded
init/action.yml	Adds repository-owner-type input to detect user-owned repositories
lib/init-action.js	Generated JavaScript output (mirrors TypeScript changes)

[mbg]

This is a great first stab at this, thank you! ✨

A few suggestions and questions, but generally this looks good.

[mbg]

Move this to init.ts or properties.ts, add a JSDoc, and some unit tests?

[mbg]

Thank you for addressing all of my feedback! 🏆

This looks good to me. I added a couple of minor comments. Not blocking, but one to think about with respect to dynamic workflows if you haven't checked yet.

[mbg]

Minor: These are the same comments as for the types, but these are actually functions constructing values of those types. How about "Constructs a success result", and similarly for the failure case below?