GitHub Enterprise 3.2替代Jenkins生成发布变更日志方法咨询

先搞懂Jenkins「最近变更」的逻辑 #

Jenkins的这个功能核心很直白：

• 每次基于master分支构建时，它会自动记录当前构建对应的master分支HEAD commit哈希。
• 下次构建时，它会拿新的master HEAD和上一次构建记录的HEAD做对比，提取这两个commit节点之间所有合并到master的提交——不管这些提交最初是在develop分支开发，还是在master直接做的热修复，只要是在两次构建的时间点之间被合并到master的，都会被纳入变更日志。
• 底层类似执行了git log <上一次构建的commit>..<当前构建的commit> --oneline这类命令，把输出整理成易读的变更列表。

在GitHub Enterprise 3.2上实现相同效果 #

结合你的部署流程（每次部署生成GitHub Release），可以用以下两种方式：

1. 基于Release标签手动/半自动生成 #

• 每次部署前，给当前master分支的HEAD打一个和Release版本对应的标签（比如v2.3.4），然后创建GitHub Release并关联这个标签。
• 下次部署时，找到上一个Release对应的标签，在GHE仓库页面的「Compare」功能里，输入<旧标签>...<新标签>（比如v2.3.3...v2.3.4），页面会自动展示两个标签之间所有合并到master的提交和PR。
• 把这些提交的标题整理成列表，直接填入新Release的「描述」栏即可；如果需要简化操作，也可以在本地/CI环境执行git log <旧标签>..<新标签> --pretty=format:"- %s (%an)"，把命令输出的内容复制到Release描述里。

2. 用GitHub Actions自动生成（GHE 3.2支持基础Actions功能） #

如果想完全自动化替代Jenkins的功能，可以写一个简单的Action工作流：

• 触发条件：master分支有push或者手动触发部署时
• 工作流步骤：
  • 把代码拉取到runner环境
  • 用GitHub API获取仓库最新的Release标签（可以用actions/github-script工具实现）
  • 执行git log <旧标签>..HEAD --pretty=format:"- %s (%an)"生成变更日志内容
  • 调用GitHub API创建新的Release，自动填入生成的变更日志

关键注意事项 #

• 必须用标签标记每次部署的master基准点，这和Jenkins记录每次构建的HEAD是同一个逻辑，能确保不管提交来自develop还是master热修复，只要是两次部署之间合并到master的，都会被准确捕获。
• 不要用提交的创建时间筛选，因为develop分支的提交可能很早就存在，只有合并到master的时间才是部署相关的节点，标签对应的commit正好能标记这个节点。

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