如何在GitLab CI/CD流程中结合semantic-release在构建中使用新版本号

针对你遇到的构建时无法获取semantic-release生成的新版本号问题，除了将发布任务前置外，还有以下更优的解决方案：

方案1：通过环境变量传递版本号（无需修改package.json时机） #

semantic-release在计算出新版本号后，会通过环境变量暴露这个值（官方GitLab CI镜像默认会设置RELEASE_VERSION），你可以直接在构建流程中读取这个变量，替代从package.json获取版本的逻辑：

• 配置semantic-release时，若需要手动导出版本号，可使用@semantic-release/exec插件在prepare阶段写入CI环境变量：

  {
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      ["@semantic-release/exec", {
        "prepareCmd": "echo 'RELEASE_VERSION=${nextRelease.version}' >> $CI_ENVIRONMENT_FILE"
      }],
      "@semantic-release/gitlab"
    ]
  }
  

• 构建阶段直接引用$RELEASE_VERSION：比如在Vue项目中配置VUE_APP_VERSION=$RELEASE_VERSION，React项目中配置REACT_APP_VERSION=$RELEASE_VERSION，代码里通过process.env.VUE_APP_VERSION读取版本号；或者用脚本替换代码中的版本占位符（如sed -i "s/VERSION_PLACEHOLDER/$RELEASE_VERSION/g" src/version.js）。
• 优势：无需调整流水线阶段顺序，保持"构建→发布"的常规流程，避免提前发布导致的构建失败风险。

方案2：拆分流水线为"版本准备+构建"与"正式发布"两个阶段 #

如果你的项目必须依赖package.json中的版本号，可以拆分流水线，先准备新版本代码再构建，最后发布：

1. 版本准备阶段：运行semantic-release的prepare流程，更新package.json、生成变更日志，将这些变更推送到临时分支（如release-temp）。
2. 构建阶段：拉取临时分支的代码执行构建，确保使用的是已更新的package.json。
3. 正式发布阶段：构建成功后，将临时分支的代码合并回主分支，执行semantic-release的正式发布流程（推送标签、更新GitLab Release等）。

• 优势：既保证构建使用新版本号，又遵循"发布在最后"的安全流程，避免构建失败但版本已发布的问题。

方案3：优化前置发布流程 #

如果坚持将发布任务放在构建前，可以添加预验证和回滚逻辑降低风险：

• 先以dry-run模式运行semantic-release，验证版本计算、提交分析等流程是否正常：

  npx semantic-release --dry-run
  

• 验证通过后，执行正式的semantic-release更新package.json；若后续构建失败，通过Git回滚package.json的变更：

  git checkout HEAD -- package.json
  

• 适用场景：项目依赖package.json版本号，且流水线逻辑简单，回滚成本低。

方案选择建议 #

• 优先选方案1：实现最简单，无需调整流水线结构，规避提前发布的风险。
• 若必须依赖package.json，选方案2：兼顾流程安全性和版本号准确性。
• 方案3适合已有前置发布流程，且能接受回滚逻辑的场景。

内容的提问来源于stack exchange，提问作者TehOne