Derive package short name from the schema name

[fnune]

Spun out of the #11109 review (defang).

Problem

The nightly generate-package-metadata.yml derives a provider short name from the repo slug (pulumi-<name>). When one repo publishes multiple packages, they all collapse to the same name. DefangLabs/pulumi-defang ships defang-aws, defang-gcp, and defang-azure, all resolving to defang, which causes:

• the PR branch (<short_name>/<run_id>-<run_number>) to be identical for all siblings, so they overwrite each other,
• the PR title (Publish Package Metadata <short_name>@<version>) to be identical, and
• the open-PR check (contains(prs, short_name)) to skip siblings once any one PR is open.

No repo currently publishes more than one package, so this has not surfaced in production yet.

Fix

Read the short name from the schema's own name field (which is also the registry YAML filename), falling back to the repo-slug regex only when the schema name cannot be read (non-JSON schema or fetch failure).

This is the only reliable source: the schema directory is not one (pulumi-resource-kafkaconnect -> name kafka-connect), and the repo slug is not one for multi-package repos.

Scope of change (verified against the full list)

group2 / provider_short_name only controls the nightly PR branch, title, and the open-PR skip check. It does not affect the published package name, which comes from the schema name via metadata from-github (writes <name>.yaml) and push-registry.py (publishes {source}/{publisher}/{name}). So no package is renamed or republished.

• Every existing package: derived name now equals its schema name, i.e. its existing <name>.yaml. No mislabels.
• runpod: corrects a pre-existing mislabel (repo-derived runpod-native never matched the real name runpod); the published name was and stays runpod.
• defang-aws / defang-gcp / defang-azure: now get distinct PRs instead of colliding.

Also includes the schema file in the matrix job name so sibling jobs are distinguishable in the Actions UI.

Validated with actionlint and a live curl + jq simulation of the derivation across the tricky cases and a sample of normal packages.

[claude]

Registry Review — generate-package-metadata.yml

Reviewed the single changed file (.github/workflows/generate-package-metadata.yml). Overall this is a clean, well-scoped fix with a clear explanatory comment and an accurate PR description. ✅

Verification

• Confirmed the matrix already carries schemaFile (from community-packages/package-list.json via generate_package_list.py), so ${{ matrix.schemaFile }} resolves correctly in both the job name (line 34) and the new SCHEMA_FILE env (line 66).
• Confirmed the downstream consumer (.github/actions/new-provider-version-pr/action.yml) builds the branch as ${provider_short_name}/${run_id}-${run_number} and the title as Publish Package Metadata ${provider_short_name}@.... Distinct short names therefore produce distinct branches/titles — the collision described in the PR is genuinely resolved.
• Surveyed all 94 schemaFile values: 92 are schema.json, 2 are schema.yaml. The new regex pulumi-resource-([^/]+)/schema\.(json|yaml) matches every nested-schema entry, and the root-schema entries (schema.json/schema.yaml with no pulumi-resource- prefix) correctly fall through to the existing repo-slug regex. No current entry changes its derived name.

Minor suggestions (non-blocking)

1. Extension coverage (.github/workflows/generate-package-metadata.yml, line 56) — the schema-path branch only recognizes json|yaml. If a future multi-package repo ships schema.yml, it would silently fall through to the repo-slug fallback, which is exactly the path that re-introduces the sibling-collision this PR fixes. No current entry uses .yml, so this isn't a live bug, but broadening the alternation cheaply future-proofs it:

          if [[ "$SCHEMA_FILE" =~ pulumi-resource-([^/]+)/schema\.(json|ya?ml) ]]; then

2. (json|yaml) capture group is unused — BASH_REMATCH[2] (the extension) is never read; only BASH_REMATCH[1] is used. Harmless, just noting it's a non-capturing concern only if you care about tidiness.

Other checks

• BUILD-AND-DEPLOY.md currency: this is a workflow change, but the doc doesn't describe the short-name derivation regex (only the resource-provider/push-provider-update action contracts), so no doc update is needed.
• Open-PR skip check (line 68): still uses contains() substring matching. This PR meaningfully improves it (siblings now get distinct full names like defang-aws rather than all collapsing to defang), though the general substring-matching fragility is pre-existing and out of scope here.

---

Nice fix. Mention @claude if you'd like additional review or want me to apply any of the suggestions.

[github-actions]

Your site preview for commit 6cfe7f4 is ready! 🎉

http://registry--origin-pr-11244-6cfe7f4b.s3-website.us-west-2.amazonaws.com/registry.

[github-actions]

Your site preview for commit ff7d936 is ready! 🎉

http://registry--origin-pr-11244-ff7d936b.s3-website.us-west-2.amazonaws.com/registry.

[github-actions]

Your site preview for commit ef7e39c is ready! 🎉

http://registry--origin-pr-11244-ef7e39c7.s3-website.us-west-2.amazonaws.com/registry.