MCP servers 仓库发布流程中某个包发布失败后如何用 gh run rerun --failed 重试【免费下载链接】serversModel Context Protocol Servers项目地址: https://gitcode.com/GitHub_Trending/se/servers在 modelcontextprotocol/serversMCP servers仓库中所有modelcontextprotocol/*npm 包和 Python 包都从同一个release.ymlGitHub Actions workflow 发布每个包是一个独立的 matrix job且配置了fail-fast: false——某个包发布失败只意味着这一个包没有发布已经发布成功的包保持原样。如果你作为维护者在一次 release run 结束后发现某个包在 npm 或 PyPI 上缺失RELEASING.md 给出的首选补救方式就是用gh run rerun run-id --failed在同一次 run 中只重跑失败的 job。发布失败的 job 为什么是孤立的先理解发布机制才知道重跑为什么安全以下均来自 RELEASING.md 与 release.yml发布只从release.yml发起受releaseenvironment 门控每次 deployment 必须经 required reviewer 批准。发布由维护者通过workflow_dispatch主动触发Actions → Release → Run workflow或gh workflow run release.yml没有定时/自动发布。认证在两个注册表上都是 OIDC trusted publishing——仓库中没有任何 registry tokennpm每个modelcontextprotocol/*包在 npmjs.com 上绑定了 trusted publisher绑定条件为这个仓库、workflow 文件名release.yml和 environmentrelease绑定区分大小写发布带 provenance attestations。PyPI通过 PyPI trusted publishing使用pypa/gh-action-pypi-publish。一次 release run 的流程检测自上一个 release tag 以来变更的包目录下任意.py、.ts或.md文件变更即算变更→ 打上日期版本号CalVer如2026.7.4并推送 release tag → 每个变更的包作为独立 matrix job 发布checkout 到 release tag → 安装依赖 → 双重发布防护 → 跑该包的测试Python 另加pyright→ 构建 → 发布→ 用生成的 notes 创建 GitHub release。各包 job 之间互不阻塞publish-pypi和publish-npm两个 job 的strategy均为fail-fast: false见 release.yml 与 release.yml所以一个包的失败只留下一个失败的 matrix leg。重试前要确认的前提条件执行 rerun 之前核对 RELEASING.md 中「When a publish failed」一节列出的四个条件原 run 必须先完成。如果还有 pending deploymentapprove 或 reject先处理掉之后 rerun 才能进入审批。需要一次新鲜的releaseenvironment 审批。rerun 仍然是一次release.yml在releaseenvironment 中的 run所以审批要求与原始发布相同。审批权只来自仓库设置里的 required-reviewer 列表Settings → Environments →releaserepository admin 身份本身不赋予 deployment 审批权。GitHub 的 re-run 窗口约为原 run 起 30 天。rerun 执行的是原始workflow 快照——main上后来对 workflow 的修改不会应用到 rerun。如果失败原因在 workflow 本身rerun 修不了它应走后文的「等下一次 release」路径。另外注意 rerun 的行为边界它只重跑失败的 leg且 checkout 在原始 release tag 上——发布的正是打了 tag 的代码。已经发布过的包由双重发布防护double-publish guard保护防护按注册表不同npm job 在版本已存在时于测试前中止见 release.yml 中的 Check if version exists on npm 步骤PyPI 则在发布步骤本身跳过upload action 的skip-existing见 release.yml。执行重试命令gh run rerun run-id --failed --repo modelcontextprotocol/servers把run-id替换为那次失败的 release run 的 Actions run ID。--failed把重跑范围限定在失败的 job 上已发布成功的包对应的 leg 不会被重新执行。这条路径之所以是文档推荐的默认方式是因为 rerun 仍满足 trusted-publisher 绑定仍是release.yml在releaseenvironment 中的 run并且发布的代码与原始 release tag 完全一致。如何核对目标版本是否已发布npmworkflow 自身就是用下面这条命令判断版本是否已存在于 npm 的release.yml 中的 Check if version exists on npm 步骤rerun 完成后可在包的目录src/包名下用同样的方式核对目标版本是否已出现VERSION$(jq -r .version package.json) npm view --json | jq -e --arg version $VERSION [.[]][0].versions | contains([$version])VERSION取自该包自己的package.json与 workflow 中的取法一致。需要说明在 workflow 里这条检查命中「版本已存在」意味着中止该 jobexit 1这正是 rerun 时双重发布防护的表现——如果失败发生前该版本其实已上传rerun 会在防护处停下而不是重复发布。PyPI文档没有给出独立的查询命令可以依赖的是 upload action 的skip-existing: truerelease.yml 中的注释说明 re-runs tolerate already-uploaded files即已上传的文件在 rerun 中会被直接跳过已发布的包不会因为重跑而报重复错误。rerun 不可用时怎么办如果 30 天 re-run 窗口已关闭或者修复需要改 workflow 文件rerun 用的是原始快照改不到就等下一次 release 把它带走那个失败的版本号在这个注册表上就是不存在——这是良性状态npm 和 PyPI 的版本历史不需要相互对齐。只要该包自上一个 release tag 以来有合格变更.py、.ts或.md文件它就会在下一个版本号上发布。文档明确禁止的做法RELEASING.md 的「Never」一节列了两条重试时不要碰不要用 npm token 或在本机手动发布。仓库没有 registry token手动发布会破坏 provenance/trust 链。不要指望新 dispatch 一次release.yml来重试失败的版本。版本号是日期粒度的同一天再 dispatch 会与已存在的 tag 冲突晚几天 dispatch 则是铸出一个新版本。两种方式都不会重试失败的那个版本。更多背景可参考仓库中的 RELEASING.md发布流程与失败处理全文和 release.yml各 job 的 environment、权限与防护步骤的实际配置。【免费下载链接】serversModel Context Protocol Servers项目地址: https://gitcode.com/GitHub_Trending/se/servers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考