Repository navigation
Conversation
…- W-24666922 A caller migrating Open VSX publishing to OIDC trusted publishing needs its ovsx publish step to run from the same top-level workflow file for every release channel (Open VSX's trusted-publisher match keys off the OIDC token's workflow_ref claim -- the run's initiating workflow -- and only allows one trusted-publisher registration per extension). This workflow's own inline ovsx publish, run as part of the caller's prerelease-promotion workflow, can't share that workflow_ref with a separate stable-release workflow. Adds an optional skip-ovsx input (default 'false', so every existing caller is unaffected) that lets a caller opt its ovsx leg out entirely, e.g. because it publishes Open VSX itself via a separate trusted-publishing dispatch instead.
…se.yml - W-24666922 Revises the previous commit's approach. A skip-ovsx toggle would have worked but leaves the PAT-based ovsx branch as permanent dead weight once every known caller migrates off it: vscode-promote-prerelease.yml has exactly two real callers (forcedotcom/salesforcedx-vscode, forcedotcom/apex-language-support), and both are moving their Open VSX publishing to a dedicated top-level workflow dispatched independently (see the file's new header comment for why: Open VSX's trusted-publisher match keys off workflow_ref, the run's initiating workflow, and allows only one registration per extension, so Open VSX publishing has to live in the same top-level file as each caller's stable release already uses). Removes the `ovsx` matrix leg, the skip-ovsx input, and IDEE_OVSX_PAT entirely rather than keeping an opt-out. Both callers' own migration PRs land in the same window as this one (coordinated merge order, not a runtime flag), so there's no gap where a caller's default branch would reference this file post-removal before its own compensating change is in place.
madhur310
changed the title
…ml - W-24666922 Same reasoning as the prerelease workflow's removal: this file's only real caller (forcedotcom/apex-language-support) is migrating its Open VSX publishing to a dedicated top-level workflow dispatched independently, for the same trusted-publisher workflow_ref reason documented in both files' headers. Removes the `ovsx` matrix leg and IDEE_OVSX_PAT. Also adds a `release-tag` output (surfaced from create-github-release's computed tag) so a caller can dispatch its own Open VSX publish for the exact tag this run just created, without having to recompute it.
madhur310
changed the title
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
ovsxmatrix leg from bothvscode-promote-prerelease.ymlandvscode-promote-stable.ymlentirely — no toggle, straight deletion.IDEE_OVSX_PATis no longer required by either.release-tagoutput tovscode-promote-stable.yml(the stable tag it just created), so a caller can dispatch its own Open VSX publish for that exact tag afterward.Context (revised from this PR's original approach)
Each of these reusable workflows has exactly one or two real callers (
vscode-promote-prerelease.yml:forcedotcom/salesforcedx-vscodeandforcedotcom/apex-language-support;vscode-promote-stable.yml:forcedotcom/apex-language-supportonly — confirmed via GitHub code search), and all of them are migrating their Open VSX publishing off these files' inline PAT-basedovsx publishonto a dedicated top-level workflow they each dispatch independently. That's required, not optional: Open VSX's trusted-publisher match keys off the OIDC token'sworkflow_refclaim (the run's initiating workflow), and allows exactly one trusted-publisher registration per extension — confirmed server-side ineclipse-openvsx/openvsx'sTrustedPublishingService.registerTrustedPublisher. A caller whose stable release publishes Open VSX from a different top-level file than its prerelease flow would get two differentworkflow_refvalues for the same extension, which can't both be registered.This PR originally added a
skip-ovsxinput instead of deleting the leg, to avoid a cross-repo merge-order risk. Since every known caller's own migration PR is landing in this same window, we're coordinating merge order directly instead (this PR merges alongside/after each caller's compensating PR, so no default branch is ever left referencing a@mainthat's already droppedovsxsupport before its own fix is in place) — so a permanent toggle isn't needed.Validation
actionlint: identical pre-existing shellcheck notices as before this change on both files (confirmed viagit stash/diff againstmain), zero new findings.Test plan
forcedotcom/salesforcedx-vscode's andforcedotcom/apex-language-support's migration PRspublishjobs only run thevsceleg,IDEE_OVSX_PATno longer requiredvscode-promote-stable.yml's newrelease-tagoutput resolves correctly for a caller dispatching its own Open VSX publish@W-24666922@