Changesets Action 中实现不发布包的情况下创建 GitHub Release 的技术方案

Changesets Action 中实现不发布包的情况下创建 GitHub Release 的技术方案

action 项目地址: https://gitcode.com/gh_mirrors/acti/action

在基于 Changesets 的工作流中，开发者经常遇到一个典型需求：如何在不需要实际发布 npm 包的情况下，仅通过 Changesets Action 创建 GitHub Release。本文将深入分析这一需求的实现原理和替代方案。

核心问题分析

Changesets Action 的设计逻辑决定了它必须依赖发布（publish）过程来创建 Release。这是因为：

1. 版本信息获取机制：Action 通过解析 publish 命令输出来确定需要发布的包及其版本号
2. 工作流耦合：Release 创建逻辑与发布流程深度绑定，无法独立运行
3. 元数据依赖：Release 所需的 changelog 和版本信息都来自发布过程生成的结果

技术实现限制

经过对源码的分析，发现直接修改 Action 配置无法实现该需求，原因包括：

• 缺少版本信息获取接口：Action 没有提供独立获取版本号的 CLI 命令
• 强耦合的架构设计：Release 创建逻辑完全依赖于发布流程的输出
• 元数据生成机制：Changelog 和版本信息只在发布阶段生成

替代解决方案

对于有此需求的开发者，可以采用以下完整的工作流方案：

1. 分离版本控制与发布流程

   • 使用 Changesets 仅管理版本和 changelog
   • 通过独立步骤读取 package.json 获取版本号

2. 多阶段工作流设计

   • 第一阶段：运行 Changesets 生成版本变更
   • 第二阶段：构建和部署实际应用
   • 第三阶段：基于版本信息创建 Release

3. 使用专用 Release Action

   • 采用 ncipollo/release-action 等独立工具
   • 从 CHANGELOG.md 提取发布说明
   • 根据版本号创建对应的 Git tag 和 Release

典型实现示例

以下是一个经过验证的 GitHub Actions 工作流核心结构：

1. 版本控制阶段

   • 使用 Changesets Action 生成版本变更
   • 输出变更标识供后续步骤判断

2. 版本信息获取

   • 通过 jq 工具解析 package.json
   • 将版本号存入环境变量

3. 部署阶段

   • 执行实际构建和部署操作
   • 生成部署产物

4. Release 创建阶段

   • 从 CHANGELOG 提取对应版本内容
   • 使用独立 Action 创建 Release
   • 添加通知等扩展功能

技术决策建议

对于不同场景的开发者，建议：

1. 纯前端项目

   • 保持现有 Changesets 发布流程
   • 在发布后触发部署

2. 非 npm 项目

   • 采用本文的分离式方案
   • 维护独立版本管理逻辑

3. 混合型项目

   • 区分库和应用的发布流程
   • 为应用部分实现定制化方案

未来演进方向

虽然当前 Changesets Action 存在这一限制，但社区可以考虑：

1. 解耦版本管理和发布流程
2. 提供版本信息查询接口
3. 支持可插拔的 Release 创建机制

这种架构演进将使 Action 更加灵活，适应各种复杂的 CI/CD 场景。

通过本文的分析和方案，开发者可以更好地规划基于 Changesets 的发布工作流，特别是在不需要实际发布 npm 包但需要版本管理的场景下。理解这些技术细节有助于构建更符合项目需求的自动化流程。

action 项目地址: https://gitcode.com/gh_mirrors/acti/action