Question: How can I publish a VS Code extension from a Git tag without storing a long-lived Marketplace token, and what should I check when the build passes but publishing fails?
Answer: I split the problem into packaging, federation, publisher access and Marketplace readback. Treating those as separate steps made today's 0.0.2 release straightforward to diagnose.
The 0.0.2 listing update also included the new logo, official website and documentation, instructions for the required CLI, and a contact for problems. The CLI requirement matters: the editor plugin reads generated project files; it does not install the icon library by itself.
Step 1: Prove that the extension package is good. My workflow ran TypeScript compilation, 39 tests, a build, release metadata validation and vsce package in a job that had no cloud credentials. It completed successfully before the publish request failed. That told me to investigate identity rather than alter the source code or rebuild the VSIX.
Step 2: Check the Marketplace authentication path. Direct vsce publish --oidc first failed because the client request did not match the current protocol. After a narrowly guarded client fix, the Marketplace still replied that trusted publishing was not supported. I switched to a GitHub Actions OIDC token exchanged through Microsoft Entra and passed the resulting Entra identity to vsce publish --azure-credential. This avoids putting a client secret or PAT in the repository.
Step 3: Make the federation subject match the workflow. My federated credential trusts main, but a tag-triggered GitHub workflow has a tag subject. Rather than weakening the credential, the tag job dispatches a second workflow on main. That workflow validates the stable tag, checks that it matches package.json, confirms the tag commit is on main, and builds from the tag.
Step 4: Authorize the identity in the publisher. A successful Entra login only proves that GitHub can sign into the Entra application. My next check still failed with “operation not allowed.” I fetched the identity ID from the Marketplace profile API and the publisher owner added it to the moewolf publisher as a Contributor. The publisher access check and actual publish then passed.
Step 5: Publish the reviewed bytes and read them back. Because version 0.0.2 already had a GitHub Release asset, the workflow verified its SHA-256 and compared each file with a fresh build of the tag. It retained the original VSIX and sent that artifact to Marketplace. The publish run completed, and the public extension metadata subsequently showed version 0.0.2.
The central lesson: a green build does not prove authentication, and successful login does not prove Marketplace publisher permission. Check each boundary, avoid printing credentials, and keep the package digest attached to the release.
https://moeicons.com/
https://moeicons.com/search
https://moeicons.com/docs/
Top comments (0)