Repository navigation
Conversation
…- W-24666922 openvsx-publish-release-vsix.yml and vscode-promote-prerelease.yml both ran `ovsx publish` against a PAT (-p $OVSX_PAT / $IDEE_OVSX_PAT). Switches both to `ovsx publish --trusted-publishing`, which exchanges this job's GitHub Actions OIDC ID token for a short-lived publish token instead -- requires `id-token: write`, which both workflows now grant. Open VSX's trusted-publisher config binds one identity per extension to the exact workflow file that requests the OIDC token (its job_workflow_ref). vscode-promote-prerelease.yml's `ovsx` leg previously ran its own `ovsx publish` inline, inside the same matrix job as `vsce` -- a different file from openvsx-publish-release-vsix.yml, which the stable release path uses. That would mean two different job_workflow_ref values for the same extension's Open VSX publishes, which a single trusted-publisher entry can't match. Split the `ovsx` leg out of that matrix job (GitHub Actions won't let a `uses:`-based job share a matrix with per-leg different targets) into its own `publish-ovsx` job that delegates to openvsx-publish-release-vsix.yml via `uses:`, instead of duplicating the ovsx-publish logic. Every Open VSX publish for a given extension -- stable, stable hotfix, prerelease, prerelease/emergency hotfix -- now requests its OIDC token from that one file. openvsx-publish-release-vsix.yml gained `vsix-name-pattern` and `exclude-web-vsix` inputs (both optional, default-compatible) so the delegated call can reproduce vscode-promote-prerelease.yml's existing filtering for monorepo/multi-extension callers. vsce/Marketplace publishing (VSCE_PERSONAL_ACCESS_TOKEN) is untouched.
Open VSX's trusted-publisher check matches the OIDC token's workflow_ref claim (the top-level/triggering workflow), not job_workflow_ref (the reusable workflow actually executing a job) -- confirmed against eclipse-openvsx/openvsx's TrustedPublishingService/ GitHubTrustedPublishingProviderSupport source. Consolidating this reusable workflow's ovsx leg onto openvsx-publish-release-vsix.yml never closed that gap: salesforcedx-vscode's stable and prerelease flows are started by two different top-level workflow files regardless of what runs underneath them, and Open VSX only allows one trusted-publisher registration per extension (a hard server-side check). The real fix has to live in salesforcedx-vscode's own top-level workflows instead, so this reusable workflow goes back to vsce-only. Keeps the openvsx-publish-release-vsix.yml PAT -> --trusted-publishing migration, which the new salesforcedx-vscode-side design still delegates to.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
openvsx-publish-release-vsix.ymlranovsx publishagainst a PAT (-p $IDEE_OVSX_PAT). Switches toovsx publish --trusted-publishing, which exchanges this job's GitHub Actions OIDC ID token for a short-lived publish token instead — requiresid-token: write, which this workflow now grants.vsix-name-pattern(default'*.vsix') andexclude-web-vsix(default'false') inputs, parameterizing the existingfind-based publish-loop discovery. Behavior-preserving defaults — the one existing caller (salesforcedx-vscode'spublishOpenVSX.yml) doesn't pass them, so it's unaffected.Context
This is a narrower replacement for #198 (closed). That PR also tried to consolidate
vscode-promote-prerelease.yml'sovsxleg onto this same file, on the assumption that Open VSX's trusted-publisher matching cared about which reusable workflow (job_workflow_ref) actually ran theovsx publishstep. Turns out it doesn't:GitHubTrustedPublishingProviderSupport.matches()ineclipse-openvsx/openvsxonly compares the OIDC token'sworkflow_refclaim — the top-level, triggering workflow in the repo that started the run — and only recordsjob_workflow_reffor audit, never matches on it. Sincesalesforcedx-vscode's stable and prerelease flows are started by two different top-level workflow files regardless of what runs underneath them, and Open VSX enforces exactly one trusted-publisher registration per extension server-side (TrustedPublishingService.registerTrustedPublisher), consolidating this reusable workflow never actually closed that gap.The real fix is happening in
salesforcedx-vscodeitself (a new top-level workflow both its stable and prerelease flows will dispatch into, so they share oneworkflow_ref). That design still delegates its actual Open VSX publish step to this file, so the PAT removal here is still needed — hence this narrower PR.Validation
actionlint: zero findings on the changed file.forcedotcom/salesforcedx-vscode'spublishOpenVSX.yml): no change needed, new inputs default to current behavior.Test plan
salesforcedx-vscodeworkflow ends up calling this fileovsx publish --trusted-publishingsucceeds withoutIDEE_OVSX_PAT@W-24666922@