Validate Cloudsmith and GCP OIDC configurations

[mbg]

This PR primarily adds validation for Cloudsmith and GCP OIDC configurations, so that they can be correctly propagated to the authentication proxy for private package registries.

The first few commits add a lightweight JSON schema implementation to simplify the specification and validation of different credential objects. The existing private registry configuration types are then migrated to make use of this.

We take advantage of this to simplify some of the validation and testing logic so that we have to update fewer places when adding new configuration types.

Then we add the two new configuration types.

Finally, we add validation for the replaces-base setting, which has been around for a while, but wasn't accepted until now.

I'd suggest reviewing this commit-by-commit.

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?

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

Pull request overview

This PR adds a lightweight schema-based validation layer for private registry credential objects, migrates existing start-proxy auth config parsing to use it, and extends supported OIDC configurations with Cloudsmith + GCP while also propagating the existing replaces-base flag through to proxy outputs.

Changes:

• Introduce a simple JSON schema/validator utility (validateSchema, optional, FromSchema) plus a test helper for generating schema-shaped objects.
• Refactor start-proxy auth config extraction into a dedicated validation.ts module and migrate existing credential types to schema-backed type guards.
• Add Cloudsmith and GCP OIDC configuration schemas and include replaces-base in credential propagation/output.

Show a summary per file

File	Description
src/start-proxy/validation.ts	New auth-config extraction + schema-based cloning/filtering.
src/start-proxy/validation.test.ts	Tests for schema-based auth-config extraction and key filtering.
src/start-proxy/types.ts	Migrates auth/OIDC types to schema-based validators; adds Cloudsmith/GCP; adds replaces-base.
src/start-proxy/types.test.ts	Adds pretty-print coverage for Cloudsmith/GCP and updates secret-hiding tests.
src/start-proxy.ts	Switches to new getAuthConfig and propagates replaces-base.
src/start-proxy.test.ts	Updates OIDC config tests to iterate over oidcSchemas.
src/start-proxy-action.ts	Includes replaces-base in proxy_urls output entries.
src/json/testing-util.ts	Adds makeFromSchema test helper for building objects from schemas.
src/json/index.ts	Adds schema/validator types + validateSchema implementation.
src/json/index.test.ts	Adds unit tests for required vs optional schema validation behavior.
lib/start-proxy-action.js	Generated output update (not reviewed).

Copilot's findings

Comments suppressed due to low confidence (1)

src/start-proxy/types.ts:46

• isUsernamePassword currently calls validateSchema(usernamePasswordSchema, config), but both username and password are optional in the schema, so validateSchema will return true for any object (including OIDC configs). This makes the type guard effectively meaningless/unsound. Consider requiring presence of at least one of the keys (or matching the previous behavior by requiring the relevant key(s) to exist) before returning true.

export function isUsernamePassword(
  config: AuthConfig,
): config is UsernamePassword {
  return json.validateSchema(usernamePasswordSchema, config);
}

• Files reviewed: 10/11 changed files
• Comments generated: 5

Spam

[henrymercer]

What happens when we merge this? Does the authentication proxy already support these new registries or is there more work to do?

[henrymercer]

Should this still include hasUsername(config) && "password" in config like isToken? Otherwise how are we validating that these fields are present given they are both optional in the schema?

[henrymercer]

Should the return type be json.FromSchema<S> instead? If T extends json.FromSchema<S> with some new properties, those won't be included in the output, so I think we're returning a json.FromSchema<S> rather than a T.

[henrymercer]

Perhaps mention that extra keys are fine.

[henrymercer]

Should this only include required keys to be consistent with the validation and avoid the need to specify username: null in the tests?