【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本文围绕 opencodex 仓库在 2026-07-22 执行的一次真实发布列车记录展开完整讲解其dev → preview → main → npm四层分支发布模型、版本号决策规则为什么 2.7.32 被跳过而直接发布 2.7.33、由 scripts/release.ts 驱动的五步执行协议以及ci.ymlservice-lifecycle.yml双门禁、GitHub Release 与 npm dist-tag 的最终收敛验证。读完你可以直接理解并复用这套预览线 稳定线的发布流程。一、发布列车背后的分支模型opencodex 的发布体系由四个状态层构成每次发版都要让它们严格收敛层职责本次训练前状态dev集成开发线承载社区 PR 与修复提交29763560CI success、sol 敌对评审 PASS、部署 readiness READYpreview预览发布线仅包含 dev 之上的发布 bump 提交26fd5ea9即release: v2.7.32-preview.20260722未实际部署的 bumpmain稳定发布线是 preview 的祖先304a1eab对应 npmlatestv2.7.31npm dist-tags对外发布通道latest2.7.31、preview2.7.29-preview.20260721值得注意的是本次训练开始时preview分支上已经存在一个名为v2.7.32-preview.20260722的 bump 提交release.yml的 run 虽然是 success但那次只是dry-run——npm 上根本没有2.7.32-preview版本npmpreview通道仍停留在2.7.29-preview.20260721。这正是发布列车要解决的典型状态本地/分支上版本号已前移但对外通道没有实际发布。关于 readiness 如何判定可参见同一工作流的前置记录 030_deploy_readiness.md它通过本地门禁3431 个隔离测试通过、tsc零错误、lint/privacy/locale 全绿、远程门禁Cross-platform CI success以及 sol 敌对评审三轮最终 PASS、无残留部署阻塞项三层证据判定 dev 达到READY才允许进入本次发布列车。二、版本决策为什么跳过 2.7.32 直接走 2.7.33发布前首先要确定本次要发布的版本号而这里存在一个真实的分叉点preview分支的package.json已经是2.7.32-preview.20260722若再次执行npm version 2.7.32-preview.20260722npm 会报no-change 错误版本未变化无法生成新的 bump 提交同时2.7.32-preview.20260722属于未部署版本——npm、Git 标签、GitHub Release 三处都不存在该版本的任何发布产物。因此决策是放弃 2.7.32 线沿2.7.33 线推进preview发布2.7.33-preview.20260722带日期戳的预览版main发布2.7.33稳定版2.7.32 stable 被跳过——因为它从未在任何通道部署过。这一决策背后其实是 scripts/version-line.ts 中一整套版本解析与推演逻辑稳定版走nextStableRelease基于稳定通道 tip 做 patch/minor/major 递增并检查是否存在更高 core 的 preview 阻塞当前 patch 线预览版走nextPreviewRelease稳定线确定 core 后追加-preview.YYYYMMDD日期戳若同 core 已有预览则用.序号递增如-preview.20260722.2并强制拒绝stamp 时钟回退所有候选版本最终都要通过assertAboveGlobalFloor——即必须严格高于已发布的所有版本稳定 预览防止把已发布的旧版本重新推到通道顶端。从源码结构看这套阻塞检查 全局地板机制正是为了避免 dev 分支版本线落后于 main、导致发布回归通道 tip 的隐患。三、五步执行协议scripts/release.ts 规则原文档给出了本次发布列车的执行顺序共五步preview 检出 合并 dev在 preview 上合并 dev本次 base 之后 dev 未改版本号因此预期package.json无冲突。preview 发版在 preview 分支执行bun scripts/release.ts 2.7.33-preview.20260722 --publish完整链路为preflight → bump commit → push → 等待ci.ymlservice-lifecycle.yml绿 → dispatchrelease.yml→ watch 运行结果。main 发版将 main 快进到 preview tip然后在 main 上执行bun scripts/release.ts 2.7.33 --publish。dev 收敛将 dev 快进到 main tip 并 push本地 HEAD 回到 dev。验证npm view bitkyc08/opencodex dist-tags --json核对 dist-tags并确认三个分支 tip 收敛。release.ts的完整用法见 scripts/release.ts 头部注释为bun scripts/release.ts version [--tag latest|preview] [--publish] bun scripts/release.ts --bump patch|minor|major [--tag latest|preview] [--publish] bun scripts/release.ts watch其中--bump模式会自动从远端标签 npm 通道解析下一个版本号watch模式只观察最近一次 Release run。release.ts还有几个硬性约束值得注意分支与 dist-tag 绑定preview分支只能发布preview通道main只能发布latest--tag传错会直接报错退出版本形态绑定preview 分支必须使用带-preview.的预发布版本main 必须使用无预发布后缀的稳定 SemVer工作区必须干净git status --porcelain有任何输出都会中止。3.1 preflight发布前的五道本地关卡每次release.ts运行无论 dry-run 还是--publish都会先执行完整的 preflight按序为release metadata preflightassertUnusedReleaseVersion并行检查 npm 版本、远端 Git 标签git ls-remote带 peeled 查询与 GitHub Release 三处是否已存在同名版本任一存在即拒绝assertChannelVersionMovesForward保证候选版本严格高于当前通道 tip。dependency auditbun run audit:high高危依赖审计。typecheckbun x tsc --noEmit。test suitebun test --isolate tests并刻意与 CI 保持一致——把 Worker 密集的api-storage-policy*.test.ts、api-storage.test.ts、api-usage.test.ts从通用分片中剔除、单独隔离运行源码注释明确记录了这个分组曾导致CI 全绿但发布门禁失败的教训现在门禁与 CI 使用完全相同的分组。privacy scanbun run privacy:scan。3.2 bump、push 与受保护分支的 SSH 钥匙preflight 通过后release.ts只修改package.jsonnpm version v --no-git-tag-version版本标签由 Release 工作流在 npm 发布后创建然后git add package.json git commit -m release: v${version}并 push。这里有一个关键设计main和preview都配置了要求 PR 的分支保护 ruleset管理员 bypass 是bypass_mode: pull_request——这只能合并 PR不能直接 push源码注释记录 v2.29.0 的发布正是死在这里。因此 release.ts 提供了一个专门的写权限 deploy key 通道设置OCX_RELEASE_SSH_KEY指向注册为该 rulesetDeployKeybypass actor 的私钥仅 bump push 这一次改用 SSH 目标 push通过GIT_SSH_COMMAND注入-o IdentitiesOnlyyes防止 ssh 先尝试主维护者身份导致再次被拒OCX_RELEASE_SSH_REPO可覆盖目标仓库发布 fork 时使用且必须是非凭证形态的ssh://或githost:owner/repo源码中大量校验拒绝带 userinfo 凭证的 HTTPS remote、拒绝 scp-like 密码形态、对 key 路径做 shell 引号转义都是为了一个目标fail-closed——进程即使中途崩溃分支保护也从未被削弱撤掉一把 key 就能关闭通道而不触碰仓库配置。未设置OCX_RELEASE_SSH_KEY时push 行为与普通推送完全一致对贡献者/CI 克隆无影响。3.3 双门禁等待与 dispatchpush 完成后release.ts依次等待两个工作流在发布 commit 上变绿Cross-platform CIci.yml轮询 20 分钟、10 秒间隔成功或失败都会立即返回Service lifecycleservice-lifecycle.yml因为 bump 必然触碰package.jsonservice-lifecycle 的触发路径而release.yml的 service gate 要求同一 SHA 上已有成功的 Service lifecycle run必须先等它避免 dispatch 竞态。等待之后还有一个live-remote 守卫dispatch 前通过git ls-remote重新读取远端分支的真实 head一旦发现等待 CI 期间分支被移动本地 remote-tracking ref 可能已过期立即中止发布——因为workflow_dispatch解析的是可变分支这是拒绝发布未经审计新提交的最后机会。随后执行 dispatchgh workflow run release.yml --ref branch \ -f versionversion -f tagtag \ -f expected-shareleaseSha -f dry-runboolexpected-sha参数把必须发布哪个不可变 commit传给 Release 工作流release.yml 会在发布前校验版本与分支是否匹配若分支移动则失败。最后waitForReleaseWorkflowRun找到对应 SHA 的 run 并gh run watch --exit-status --interval 10跟踪到结束。3.4 dry-run 与 --publish 的二阶段语义release.ts的默认是dry-rundryRun !args.includes(--publish)但 dry-run 也会真实 bump、commit、push目的是让 Release 工作流在真实发布 commit上完整演练。因此对同一版本二次执行--publish时package.json已处于目标版本脚本会将其视为已满足跳过npm version的 no-change 错误commit 也已存在则直接复用——这正是 dry-run 后能无缝转正的原因。四、本次训练的实际结果按上述协议执行后的最终状态均来自原文档记录全部为 2026-07-22 的实况preview 线dev29763560合并进 preview9a140a20→release.ts 2.7.33-preview.20260722 --publish→ bump 提交6c112450→ci.ymlservice-lifecycle.yml双绿 → Release run29904313855success → npmpreview2.7.33-preview.20260722GitHub Releasev2.7.33-preview.20260722。main 线main 快进到 preview tip6c112450→release.ts 2.7.33 --publish→ bump 提交6d6bef8b→ 双门禁 success → Release success → npmlatest2.7.33tagv2.7.33。收敛dev 快进到 main tip6d6bef8b并 pushpreview 也 push 到6d6bef8b——远端dev/preview/main三个分支同一 SHA6d6bef8b本地 HEAD 回到 dev工作树干净。最终 npm dist-tagslatest2.7.33、preview2.7.33-preview.20260722。dev 分支 push 后按协议惯例还确认了 dev-branch 的 CI run 结果尽管同一 SHA 在 main 上已绿仍按规矩单独确认 dev run。五、可复用的发布核对清单综合原文档与源码一次完整的 opencodex 发布列车可归纳为以下核对点readiness 前置dev 通过本地门禁isolate 测试 tsc lint/privacy/locale、远程 Cross-platform CI、敌对评审三层判定参见 030_deploy_readiness.md。版本决策检查 previewpackage.json与 npm 实际 dist-tags 的差异未部署的 bump 直接升线本次即跳过 2.7.32 走 2.7.33preview 用X.Y.Z-preview.YYYYMMDD形态main 用稳定 SemVer。顺序执行preview 合并 dev → preview 发版 → main 快进 发版 → dev/preview 收敛到同一 SHA →npm view bitkyc08/opencodex dist-tags --json终验。门禁确认ci.yml与service-lifecycle.yml必须在同一发布 commit 上双绿dispatch 必须携带expected-sha发布后核对 GitHub Release tag 与 npm dist-tag 一一对应。参考文件发布列车执行记录本文主体040_release_train.md部署 readiness 判定030_deploy_readiness.md发布辅助脚本scripts/release.ts版本线与推演逻辑scripts/version-line.tsRelease 工作流dry-run 默认、dist-tag 选项、expected-sha守卫release.yml双门禁ci.yml、service-lifecycle.yml赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐opencodex 双通道发布流水线实战从 dev 合并到 npm 的 latest/preview 双 dist-tag 发布opencodex 双通道发布流水线实战从 dev 合并到 npm 的 latest/preview 双 dist tag 发布 opencodexUnivOpenCodex v2.7.21 发布火车全解析从 dev 同步、PR 集成加固到双通道 npm 发布的工程实践OpenCodex v2.7.21 发布火车全解析从 dev 同步、PR 集成加固到双通道 npm 发布的工程实践 本文以 OpenCodexUniversopencodex 预览通道Preview受控发布实战从 preview 分支到 npm dist-tag 的端到端流程opencodex 预览通道Preview受控发布实战从 preview 分支到 npm dist tag 的端到端流程 导读 本文以 opencodex上一篇DeepLearnToolbox完整教程如何在MATLAB中快速掌握深度学习算法下一篇终极Zotero检索引擎清单一键提升学术研究效率300%创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考