Repository navigation
ci: wait for npm before the registry publish; run the release workflow for an existing tag - #223
Merged
Merged
Conversation
…flow run for an existing tag The v0.8.0 run published to npm, then failed at the MCP registry because npm did not show the version yet (it appeared about a minute later). After npm publish the workflow now waits up to 5 minutes for the version to show, as the codegraph release workflow does, and skips npm publish for a version npm already has. A tag's own release.yml is the copy from its commit, so a fix cannot reach an existing tag by re-running it. workflow_dispatch takes a tag input, runs on main, checks out that tag and applies the same guards: the tag equals v plus the package.json version and its commit is on main. CONTRIBUTING.md describes the recovery run.
Owner
Author
|
@coderabbitai full review |
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.
The 0.8.0 release run published to npm and then stopped at the MCP registry step: npm did not show 0.8.0 yet, and the registry checks the npm package when it validates the entry (run). npm showed the version about 53 seconds later. This PR fixes that and lets the fixed workflow finish the existing tag.
Changes to
.github/workflows/release.ymlnpm publishis skipped whennpm view swarmail-mcp@<version>already shows the version.npm viewcapped at 30 s) and fails with an error naming the package and version. It runs before the registry publish. This is the skip-and-wait patternbompus/codegraph's release workflow already uses.workflow_dispatchtakes a requiredtaginput. A tag's ownrelease.ymlis the copy from its commit, so re-running a failed tag run cannot pick up this fix; the workflow has to run onmainand check out the tag. Thecheckjob requires the run to be onmain, the tag to equalvplus thepackage.jsonversion, and the checked-out commit to be inmain's history. It passes that commit's SHA topublish, which checks out exactly that SHA, so moving the tag mid-run cannot change what gets published. Push-triggered runs behave as before.gh release createuses$TAG.CONTRIBUTING.mdstep 3 says how to run the workflow again for a tag, and not to use "Re-run failed jobs".Review. An independent non-Anthropic review walked the one planned dispatch for
v0.8.0(npm already has it, the registry has 0.7.2, no GitHub release) and found no blocker there. It raised two things, both fixed here: the publish job re-resolved the tag instead of using the commit the check job validated, and the "5 minutes" claim was not enforced whennpm viewhung.actionlintreports only that it does not know the documentedqueueconcurrency key, which GitHub accepted on the real run. The loop's timeout path was exercised locally against the real registry (exit 1 with the error line).Not verified until the dispatch: the registry publish after the wait, and the GitHub release step.