[madhur310]

Summary

• openvsx-publish-release-vsix.yml: migrates ovsx publish from a PAT (-p $IDEE_OVSX_PAT) to ovsx publish --trusted-publishing (requires id-token: write, now granted). Adds optional vsix-name-pattern/exclude-web-vsix inputs (behavior-preserving defaults).
• vscode-promote-prerelease.yml / vscode-promote-stable.yml: removes the ovsx matrix leg entirely (no toggle) — IDEE_OVSX_PAT no longer required by either. Adds a release-tag output to vscode-promote-stable.yml (the stable tag it just created).
• vscode-manual-publish.yml: its publish job's ovsx leg becomes a deliberate no-op step (matrix entry and job status unchanged, so every downstream needs.publish.result == 'success' check in this file is unaffected). Adds a hard error in prepare for source-run-id + registries: ovsx/all, since that path has no GitHub Release for a tag-based trusted-publishing dispatch to target.

(Previously split across this PR and #200 — folded into one here since all of these are the same migration and it's simpler to coordinate one github-workflows branch against each calling repo's own migration PR.)

Context

Open VSX's trusted-publisher match keys off the OIDC token's workflow_ref claim — the run's initiating workflow — not job_workflow_ref (the reusable workflow actually executing a job, which can be nested arbitrarily deep via uses:, even cross-repo, without changing workflow_ref). Open VSX also allows exactly one trusted-publisher registration per extension, enforced server-side (TrustedPublishingService.registerTrustedPublisher in eclipse-openvsx/openvsx) — not just a UI limitation.

Each caller of these reusable workflows was publishing Open VSX from these files' inline PAT-based leg, while also having one or more other top-level workflows for its other release channels — different workflow_ref values for the same extension, which can't all be registered. forcedotcom/salesforcedx-vscode has two such channels (stable, prerelease); forcedotcom/apex-language-support has three (prerelease, stable, and a manual/break-glass publish path). Each caller is migrating Open VSX publishing onto one dedicated top-level workflow that every one of its channels dispatches/triggers directly (not nested via uses:), delegating the actual publish step to this PR's openvsx-publish-release-vsix.yml. That makes removing/redirecting the old PAT-based legs here required, not just cleanup — otherwise every publish double-publishes to Open VSX and IDEE_OVSX_PAT can never be retired.

Validation

• actionlint on all four changed files: zero new findings vs. main (confirmed via git stash/diff — same pre-existing shellcheck notices as before, exact counts matched).
• Traced every real caller of all four files via GitHub code search (vscode-promote-prerelease.yml: 2 callers; vscode-promote-stable.yml and vscode-manual-publish.yml: 1 caller each; openvsx-publish-release-vsix.yml: 1 caller) to confirm none are left unaccounted for.
• End-to-end confirmed against both calling repos, dispatching each one's publishOpenVSXTrusted.yml (pinned to this branch) for real against an already-published, --skip-duplicate-safe tag — no new content reached the registry:
  • forcedotcom/apex-language-support (1 extension): run 41496313940 / publish job — 🔐 Trusted publishing token issued for salesforce.apex-lsp-vscode-extension logged, publish step completed via --skip-duplicate.
  • forcedotcom/salesforcedx-vscode (all 17 Open VSX-published extensions): run 41499926285 / publish job — trusted publishing token issued for every extension, zero ❌ No trusted publisher matches errors.

Test plan

• forcedotcom/salesforcedx-vscode's and forcedotcom/apex-language-support's migration PRs validate end-to-end against this branch before merge
• Coordinate merge order: this PR merges alongside/after each caller's compensating PR
• Register the Open VSX trusted publisher for each affected extension against its new top-level workflow file
• Confirm a real (or --skip-duplicate-safe) publish logs 🔐 Trusted publishing token issued for salesforce.<extension> / ...apex-lsp-vscode-extension
• Confirm vscode-manual-publish.yml's new validation fires for source-run-id + registries: all

@W-24666922@

[mshanemc]

can we have a README file about this and link to it instead of spamming the same comments on every file

[mshanemc]

I think this belongs not in the workflow as a comment, but in the repo's docs. Look at it's top-level repo where it outlines various scenarios for npm, gh releases, etc. Maybe like that?

[mshanemc]

approved w/ non-blocking comments