GitHub Actions 自动打包发布版本日志的核心是通过工作流串联构建、生成变更日志、创建 Release、上传资产四环节；关键在于选用现成 Action（如 action-automatic-releases）并配置正确触发条件（如 git tag v*），配合项目定制打包命令与可选的 conventional-changelog 增强日志可读性。

GitHub Actions 自动打包并发布版本日志，核心是用一个工作流（workflow）串联“构建 → 生成变更日志 → 创建 Release → 上传资产”四个环节。关键不在于写多少代码，而在于选对现成 Action 并配对触发条件。

明确触发时机

自动发布的前提是知道什么时候该执行。最常用两种方式：

• 推送到特定分支（如 main 或 release/*），适合每次合并就发布正式版
• 创建 Git 标签（git tag v1.2.0），更推荐——标签天然对应版本号，语义清晰且不易误触

示例配置片段：

on:
  push:
    tags: ['v*']  # 匹配 v1.0.0、v2.3.4 等格式

用 action-automatic-releases 一键生成 Release

这是目前最轻量、覆盖最全的开源方案（来自 marvinpinto/action-automatic-releases）。它能自动完成：

• 从提交历史提取 feat/fix/breaking 变更，生成结构化 changelog
• 根据 tag 名创建 GitHub Release 页面
• 支持通配符上传构建产物（比如 dist/*.zip、build/*.jar）
• 识别预发布标签（如 v2.0.0-rc.1），自动标记为 pre-release

只需在 workflow 中加入：

MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub

使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...

下载

- uses: marvinpinto/action-automatic-releases@latest
  with:
    repo_token: ${{ secrets.GITHUB_TOKEN }}
    prerelease: false
    files: |
      dist/my-app-*.tar.gz
      README.md

打包步骤需按项目类型定制

打包本身不是 GitHub Actions 的职责，而是调用你项目的构建命令。常见模式：

• Node.js：运行 npm run build 或 pnpm build，输出到 dist/
• Java/Maven：执行 mvn clean package，生成 target/*.jar
• Python：用 build 工具生成 dist/*.whl 或 dist/*.tar.gz
• Go：go build -o myapp ./cmd，产出二进制文件

打包后建议加一步验证，比如检查输出目录是否存在文件，避免空 Release。

变更日志可额外增强可读性

action-automatic-releases 默认基于 conventional commits（如 feat:、fix:）生成日志，但你可以：

• 在 workflow 中前置运行 conventional-changelog-action，生成独立 CHANGELOG.md 并提交
• 把生成的 CHANGELOG.md 作为 Release 正文的一部分（通过 github_release_body 参数传入）
• 禁用默认日志生成，只上传你手动维护的 CHANGELOG.md 文件

这样既能保留人工审核空间，又不破坏自动化流程。