The loadUserConfig function uses isLocal to determine if a provided configFile path is local or remote. The logic in isLocal is based on the OLD_REMOTE_ADDRESS_FORMAT where all components are required and the presence of an @ character is used as an indicator that the address refers to a remote file.

With the changes from #3973, the new remote address format makes all components, except the repository name, optional. Therefore, a new-style remote address may not contain an @ character. I added a test case which demonstrates the resulting failure in 3ac4070.

Working around this issue is slightly complicated, because it is (in general) impossible to distinguish between a relative, local path like foo.yml and a repository name (foo.yml is also a valid repository name).

The approach I have taken here to resolve this is principally that:

• The result of userConfigFromActionPath always refers to a local file.
• If the existing isLocal predicate holds:
  • If it is relative to the workspace and the file exists, it is a local file.
  • Otherwise:
    • If the FF is on OR the path is explicitly local (starts with ./), then we throw the relevant error depending on whether the absolute path is within the workspace or not.
    • Otherwise, we treat the path as a remote address.
• Otherwise, we treat the path as a remote address.

This has the effect that:

• If the FF for Support shorthand forms for getRemoteConfig #3973 is off, the behaviour is as it was previously (all tests with the FF off behave as before).
• Otherwise, in the case of ambiguity, we give precedence to local files and only attempt to load a remote file if there is no matching local one.

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.
• Code Quality - The changes impact analyses when analysis-kinds: code-quality.
• Other first-party - The changes impact other first-party analyses.

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.
• 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?

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