Extend registry checks to the development registry

[JeffreyCA]

Closes #9234

This PR extends the existing extension registry approval policy to cli/azd/extensions/registry.dev.json, applying the same validation and CODEOWNERS rules currently used for the production registry.

Changes

• Trigger ext-registry-check when either production or development registry changes, including rename scenarios.
• Independently evaluate each changed registry through the existing metadata, release immutability, version progression, capability, provider, and artifact URL policies.
• Allow registry-only PRs to update either or both registry files while continuing to require core review for unrelated file changes.
• Assign registry.dev.json the same CODEOWNERS as registry.json.

Testing

• npm test: 54 tests passed, with 5 opt-in live tests skipped.
• RUN_LIVE_TESTS=1 npm test: all 59 tests passed, including the existing real GitHub PR scenarios.
• End-to-end canary using a temporary workflow and draft PR JeffreyCA/azure-dev#53:
  • A cosmetic registry.dev.json display-name update passed.
  • A restricted namespace update failed as expected, reporting that core review was required for the registry.dev.json metadata change.
  • The canary PR was closed and all temporary branches were deleted after testing.

[azure-pipelines]

Azure Pipelines:
22 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
22 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Extends extension registry approval checks and ownership rules to the development registry.

Changes:

• Detects and validates changes to either registry, including renames.
• Supports registry-only updates affecting one or both registries.
• Adds equivalent CODEOWNERS coverage and tests.

Show a summary per file

File	Description
.github/workflows/ext-registry-check.yml	Detects changes to both registries.
.github/scripts/src/ext-registry-check.js	Applies policy checks independently per registry.
.github/scripts/test/ext-registry-check.test.js	Tests development and dual-registry updates.
.github/CODEOWNERS	Assigns development registry owners.

Review details

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

[richardpark-msft]

Small stuff - generally, I dislike default values as they usually just lead to weird bugs. There's no compat requirements for that function, so change the signature at will :)

[richardpark-msft]

Sorry, meant to use request changes earlier.

[jongio]

The per-registry loop and dual-path detection look correct, and the tests cover the dev-only and both-registries cases. One follow-on tied to the existing request to drop the registryPath defaults: see the inline note on DEFAULT_REGISTRY_JSON_PATH.

[Copilot]

Review details

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

[jongio]

Confirmed the removed defaults are safe: run() passes registryPath and registryBaseRef explicitly at every call site, and falls back to base sha then 'main' before invoking the check. My earlier note about the dangling DEFAULT_REGISTRY_JSON_PATH constant is resolved.

[JeffreyCA]

/check-enforcer evaluate

[richardpark-msft]

Thanks for addressing the feedback. Now...you just have copilot to deal with.

[Copilot]

Review details

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

[jongio]

The new commit resolves the two open threads on the last revision. diffChangedFiles now emits separate, correctly-directed messages for non-registry edits versus registry renames, and the added test drives per-path fixtures with one policy-invalid registry so independent per-registry evaluation is actually exercised. Re-approving on the current HEAD.

[jongio]

Re-reviewed against 40743ce. The multi-registry refactor is correct: the allowed-update check runs per changed registry, diffChangedFiles flags non-registry edits and registry renames for core review, and the workflow pre-check mirrors the script including the rename (previous_filename) case. Tests cover dev-only, both-registries, rename, and independent per-registry evaluation. My earlier note about the unused default path was addressed.

[Copilot]

Review details

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

[JeffreyCA]

/check-enforcer override

[jongio]

Two things, neither blocking.

ext-registry-ci.yml still only triggers on registry.json, so a dev-registry-only PR gets no schema or dependency validation at all. cli-ci.yml excludes cli/azd/extensions/**, and the validation step runs -run '^TestRegistryFileIsValid$', which doesn't match TestDevRegistryFileIsValid. That test is already written against registry.dev.json but nothing in PR CI fires it.

This matters more after this PR: registry.dev.json moves off the /** catch-all (6 owners) onto the registry maintainer list (17 owners), and it can now take the no-core-review fast path. So the set of people who can land a dev registry change grows while the validation gate stays prod-only.

Two edits in ext-registry-ci.yml:

paths:
  - "cli/azd/extensions/registry.json"
  - "cli/azd/extensions/registry.dev.json"
  - ".github/workflows/ext-registry-ci.yml"

go test ./pkg/extensions -run '^(TestRegistryFileIsValid|TestDevRegistryFileIsValid)$' -v

verify-ext-providers.yml already uses that multi-test regex form, so it matches what's there.

Happy to see this as a follow-up rather than in this PR, but the two gates drifting apart is the kind of thing that stays broken quietly.

[Copilot]

Review details

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

[jongio]

Re-reviewed against 177da8e. The deletion and rename-away handling is correct. Removed registry paths are excluded from the fetch loop, so a deleted registry surfaces as a policy reason instead of the old "Not Found" internal error, and isRegistryFile classifies a registry renamed away as a rename rather than an unrelated outside file. The added tests cover both cases with negative assertions that getContent isn't called and no internal-failure message is emitted. The workflow comment now matches actual behavior: previous_filename is only set on renames, and deletions stay covered by the filename check.

[jongio]

Re-confirmed against 177da8e. The per-registry evaluation, rename, and deletion paths all behave as intended and are exercised by the added tests. Deleted or renamed-away registries surface as policy reasons instead of hitting the content fetch, and the workflow's registry_changed output rename is applied consistently across both gate conditions. Nothing changed since my last review on this commit. Approving.

[jongio]

Reviewed the latest revision end to end. Each registry is evaluated independently, deleted and renamed registries route to core review without attempting a head fetch, and the check still fails closed on any internal error. Dev-registry, both-registry, rename-in, rename-away, and delete paths are all covered by tests. Nothing blocking from me.