Skip to content

Use private registry proxy for API requests when available#4007

Open
mbg wants to merge 19 commits into
mainfrom
mbg/use-registry-proxy-for-repo-auth
Open

Use private registry proxy for API requests when available#4007
mbg wants to merge 19 commits into
mainfrom
mbg/use-registry-proxy-for-repo-auth

Conversation

@mbg

@mbg mbg commented Jul 13, 2026

Copy link
Copy Markdown
Member

This PR allows the CodeQL Action to use the private registry authentication proxy when fetching remote configuration files. The authentication proxy is available in Default Setup workflows. Doing so allows configuration files to be retrieved from private repositories, provided that a suitable git_source registry is set up for the organisation.

#4000 has laid the groundwork for this, by always enabling git_source registries when they are available.

The change is behind a new FF.

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:

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

@mbg mbg self-assigned this Jul 13, 2026
@github-actions github-actions Bot added the size/S Should be easy to review label Jul 13, 2026
@mbg mbg force-pushed the mbg/use-registry-proxy-for-repo-auth branch from fcdd601 to b6d92e3 Compare July 13, 2026 15:17
@github-actions github-actions Bot added size/M Should be of average difficulty to review and removed size/S Should be easy to review labels Jul 14, 2026
@mbg mbg marked this pull request as ready for review July 14, 2026 16:16
@mbg mbg requested a review from a team as a code owner July 14, 2026 16:16
Copilot AI review requested due to automatic review settings July 14, 2026 16:16
@mbg

mbg commented Jul 14, 2026

Copy link
Copy Markdown
Member Author

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Adds feature-flagged registry-proxy support for retrieving remote CodeQL configuration files from private repositories.

Changes:

  • Adds proxy environment handling and Undici-based API routing.
  • Routes remote configuration requests through the proxy when enabled.
  • Adds unit and PR-check coverage.
Show a summary per file
File Description
src/api-client.ts Implements proxy-aware API clients.
src/api-client.test.ts Tests proxy configuration.
src/config/file.ts Proxies remote configuration requests.
src/config/file.test.ts Tests feature-flagged proxy selection.
src/environment.ts Defines proxy variables and environment cloning.
src/feature-flags.ts Adds the proxy feature flag.
src/testing-utils.ts Isolates environments between test-builder clones.
pr-checks/checks/start-proxy.yml Exercises proxy-backed initialization.
package.json Adds Undici.
package-lock.json Locks the dependency update.
lib/entry-points.js Generated artifact; excluded from review.
.github/workflows/__start-proxy.yml Generated workflow; excluded from review.

Review details

Files excluded by content exclusion policy (2)
  • .github/workflows/__start-proxy.yml
  • lib/entry-points.js
  • Files reviewed: 9/12 changed files
  • Comments generated: 1
  • Review effort level: Medium

Comment thread src/config/file.test.ts Outdated
Comment thread src/api-client.test.ts

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing some tests for RegistryProxyVars.PROXY_CA_CERTIFICATE:

  • requestTls is defined when RegistryProxyVars.PROXY_CA_CERTIFICATE is defined
  • requestTls is undefined when RegistryProxyVars.PROXY_CA_CERTIFICATE is not defined

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not aware of any nice way of inspecting this once the ProxyAgent has been constructed. The e2e test exercises this though. Since it is given a remote address, the API request is made via the proxy and wouldn't work if requestTls wasn't set up correctly.

with:
languages: java
tools: ${{ steps.prepare-test.outputs.tools-url }}
config-file: codeql-action@main:tests/multi-language-repo/.github/codeql/custom-queries.yml

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe #4014 added support for a local prefix?

Suggested change
config-file: codeql-action@main:tests/multi-language-repo/.github/codeql/custom-queries.yml
config-file: ./tests/multi-language-repo/.github/codeql/custom-queries.yml

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is intentionally a remote address so that the CodeQL Action fetches the file via the proxy in this test.

Comment thread src/config/file.test.ts
Comment on lines +109 to +134
// Should use it when the FF is enabled and the environment variables are set.
await target
.withFeatures([Feature.ProxyApiRequests, Feature.NewRemoteFileAddresses])
.withEnv((env) => {
env.set(RegistryProxyVars.PROXY_HOST, "localhost");
env.set(RegistryProxyVars.PROXY_PORT, "1234");
})
.logs(t, "Using private registry proxy at 'http://localhost:1234'")
.passes(t.truthy);

// But not when the FF is not enabled.
await target
.withFeatures([Feature.NewRemoteFileAddresses])
.withEnv((env) => {
env.set(RegistryProxyVars.PROXY_HOST, "localhost");
env.set(RegistryProxyVars.PROXY_PORT, "1234");
})
.notLogs(t, "Using private registry proxy at 'http://localhost:1234'")
.throws(t, { message: errorMessage });

// And not when the environment variables aren't set.
await target
.withFeatures([Feature.ProxyApiRequests, Feature.NewRemoteFileAddresses])
.notLogs(t, "Using private registry proxy at 'http://localhost:1234'")
.throws(t, { message: errorMessage });
});

@mario-campos mario-campos Jul 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that these should be three individual unit tests—per best-practice. But, that's quite a lot of boilerplate setup code to duplicate. You could put it into a helper setup method, but not crazy about that either. I'll leave that up to you whether to keep as-is, or split/refactor.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no strong feelings here. I can break this up into three separate tests, but these can also be viewed as three separate assertions. Not duplicating the boilerplate isn't hard.

Comment thread src/api-client.ts
Comment on lines +100 to +108
export function makeProxyRequestOptions(
dispatcher: ProxyAgent,
): RequestRequestOptions {
return {
fetch: (req: RequestInfo, init?: RequestInit) => {
return undiciFetch(req, { ...init, dispatcher });
},
};
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems very similar to getApiFetch. Perhaps there's a way to combine the two? Or have getApiFetch call makeProxyRequestOptions.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getApiFetch is unused and left over from when I had hoped to perform the FF check in createApiClientWithDetails. Since it is unused, I will remove it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/M Should be of average difficulty to review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants