Add support for updating dev registry in extension release pipelines

[JeffreyCA]

Addresses #8179

Follow-up to #8167 to be able to automatically publish to and update the dev registry (registry.dev.json) instead of registry.json.

Note: Publishing to the dev registry still creates the same public GitHub release tag and storage artifacts as a production registry publish. Use a prerelease/dev version for dev-registry publishes to avoid colliding with a later production publish of the same version.

Validation

Tested pipeline on ext-dev-registry branch with Skip.Publish=true confirmed azure-sdk bot auto-submitted PR with expected changes: #8253

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a PublishToDevRegistry pipeline parameter that allows extension release pipelines to publish to the dev registry (registry.dev.json) instead of the production registry (registry.json).

Changes:

• Added PublishToDevRegistry parameter to all individual extension release pipeline YAMLs and propagated it through release-azd-extension.yml to publish-extension.yml.
• In publish-extension.yml, conditionally set registry file name, PR branch prefix, and PR title based on the new parameter.
• Updated the azd x publish step and create-pull-request template usage to reference the parameterized registry file and PR metadata variables.

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated no comments.

File	Description
eng/pipelines/templates/stages/publish-extension.yml	Adds parameter and conditional variables; switches hardcoded registry/PR strings to variables.
eng/pipelines/templates/stages/release-azd-extension.yml	Forwards new parameter to publish-extension template.
eng/pipelines/release-ext-*.yml (16 files)	Adds the PublishToDevRegistry parameter and forwards it to the release template.

[wbreza]

Thanks for the follow-up to #8167 — the threading across all 15 per-extension pipelines and the wrapper template is clean and consistent, and the default-off conditional keeps existing pipelines fully insulated. A few things worth considering before merge:

🟡 Update_Registry job runs unconditionally for dev publishes

In �ng/pipelines/templates/stages/publish-extension.yml, the Update_Registry job still executes its Refresh Fig/Usage snapshots step (go test ./cmd -run 'TestFigSpec|TestUsage' with UPDATE_SNAPSHOTS=true) regardless of PublishToDevRegistry. Those snapshots are global fixtures, not per-registry — so a dev-registry publish can produce snapshot diffs that end up in the dev-registry PR. If such a PR ever merges, it would pollute the snapshots that production-registry CI depends on.

Two reasonable options:

• Gate the snapshot-refresh step (or the whole Update_Registry job) on ${{ parameters.PublishToDevRegistry }} == false so dev publishes only update
  egistry.dev.json and skip the snapshot regeneration entirely.
• Or, if the snapshots are genuinely registry-independent (i.e., TestFigSpec/TestUsage don't read the registry file at all), add a brief comment explaining why the refresh is safe under both modes so future maintainers don't have to re-derive that.

🟡 Release tag is shared between dev and prod publishes

Publish_Release is not parameterized — it always creates the public GitHub release tagged �zd-ext-_ and uploads artifacts to the production storage location. So a "dev registry publish" still consumes a real version tag and ships public binaries; only the registry pointer differs.

This is probably the intended design (dev registry is a publish-channel choice, not an isolation mechanism), but it has a sharp edge: if someone runs the dev pipeline with a version that later gets reused for a prod publish, gh release create will collide on the existing tag. A short note in the PR description, or a one-line displayName hint on the dev path (e.g., reminding operators to use a pre-release suffix like -alpha/-dev), would prevent that footgun.

🔵 Nit — TestDevRegistryFileIsValid could assert empty extensions

In cli/azd/pkg/extensions/registry_files_test.go, consider adding
equire.Empty(t, registry.Extensions) to document the intent that
egistry.dev.json ships empty as a seed. Optional.

Verified clean

• Parameter threading across all 15 per-extension pipelines →
  elease-azd-extension.yml → publish-extension.yml is correct and consistent
• cli/azd/extensions/registry.dev.json exists and parses against the schema
• �zd x publish --registry accepts the new dev-registry path
• The comment on the Update_Registry job was updated to reflect the generalization
• Distinct PR branch prefix (�xt-dev-registry-update/) and title prevent collisions with production registry-update PRs

Nice clean implementation overall — the conditional approach is the right call here.

[JeffreyCA]

Addressed the feedback: dev-registry publishes now skip the global Fig/Usage snapshot refresh, the PR description calls out that dev publishes still consume the same public release tag/artifacts as prod publishes, and TestDevRegistryFileIsValid now asserts the dev registry seed is empty.