Proposal: Rearchitect Release Pipeline for Trusted Publishing#2346
Open
dividedmind wants to merge 3 commits intomainfrom
Open
Proposal: Rearchitect Release Pipeline for Trusted Publishing#2346dividedmind wants to merge 3 commits intomainfrom
dividedmind wants to merge 3 commits intomainfrom
Conversation
Documents a proposal for re-architecting the monorepo's release pipeline. This plan addresses the challenges of adopting npm trusted publishing (OIDC) in a multi-package environment with native binary assets. It proposes using stable, "floating" Git tags for client discovery via the GitHub Releases API, eliminating the `npm dist-tag` dance and race conditions. The proposal also includes support for enterprise asset mirroring and mandates checksum verification for enhanced security.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds an architecture proposal to modernize the AppMap monorepo release pipeline to support npm trusted publishing (OIDC) by shifting “latest” discovery from npm dist-tags to Git/GitHub constructs (floating/stable tags) and GitHub Releases.
Changes:
- Introduces a “floating stable tag” model (e.g.,
appmap-latest,scanner-latest) intended to eliminate the publish/retag race. - Proposes CI/CD workflow changes to enable OIDC publishing and to move stable tags only after binaries are uploaded.
- Proposes IDE client changes to discover/download tools via GitHub Releases API, with enterprise mirroring support.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Updates the trusted publishing architecture proposal (`architecture/trusted-publishing-proposal.md`) to incorporate several crucial refinements based on feedback and further analysis: - Changes the architecture to use a dedicated orphan branch instead of a floating tag. - Explicitly notes the removal of the `verifyConditionsCmd` from `.releaserc.js`, which previously checked for `YARN_NPM_AUTH_TOKEN`. - Adds an action item to remove the obsolete generation and uploading of `.sha256` files, as digest verification will now occur via the manifest.
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 8 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
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
1 participant
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.
While rotating the NPM token and looking into trusted publishing I dug a little bit into pipeline architecture and have ideas on how to improve it. The basic concept is:
latest— current workflow is 1) publish asnext, 2) build and publish binaries on github, 3) retag on npm aslatest. This was used by IDE plugins to ensure they don't try to download versions that don't have binaries published yet.(Note since feat: GitHub Releases for CLI & improved asset updates vscode-appland#1106 and feat: Use GitHub releases for CLI version checks appmap-intellij-plugin#919 they check directly on GitHub anyway, which I now realize is racy because we don't mark the release as draft before building and attaching binaries.)
Benefits:
@kgilpin @hleb-rubanau wdyt?