Fix new remote address being handled as local file by loadUserConfig

[mbg]

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.

[Copilot]

Warning

• Copilot's review of this pull request may be incomplete because some of the changed files are excluded by your Copilot content exclusion settings. See Excluding content from Copilot for details.

Pull request overview

Fixes shorthand remote configuration addresses being mistaken for local paths.

Changes:

• Refactors new-format remote address parsing.
• Revises local-versus-remote configuration resolution.
• Adds local and remote loading tests.

Show a summary per file

File	Description
src/config/remote-file.ts	Extracts new-format address parsing.
src/config-utils.ts	Updates configuration source selection.
src/config-utils.test.ts	Adds loading behavior tests.
lib/entry-points.js	Generated artifact; excluded from review.

Review details

Files excluded by content exclusion policy (1)

• lib/entry-points.js

• Files reviewed: 3/4 changed files
• Comments generated: 4
• Review effort level: Medium

[mbg]

For backwards-compatibility reasons, we cannot rely on local paths starting with ./. Adding such a requirement would break existing configurations.

That said, I am also not convinced that this is a real concern. While an analysis may end up using a local configuration file in a PR branch, rather than a remote one that was intended, this would be very obvious.

Currently, the same thing could be done in any repository that uses a custom workflow by changing the configuration file in the repo, adding one and setting config-file, or setting the config input.

[mbg]

I don't believe that input paths are expected to be absolute or that it is really supported since paths have to be relative to the workspace root.