29 KiB

Raw Permalink Blame History

name: Update Main Version
run-name: Move ${{ github.event.inputs.major_version }} to ${{ github.event.inputs.target }}

permissions:
  contents: write

on:
  workflow_dispatch:
    inputs:
      target:
        description: The tag or reference to use
        required: true
      major_version:
        type: choice
        description: The major version to update
        options:
          - v1

jobs:
  tag:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        fetch-depth: 0
    - name: Git config
      run: |
        git config user.name github-actions
        git config user.email github-actions@github.com
    - name: Tag new target
      run: git tag -f ${{ github.event.inputs.major_version }} ${{ github.event.inputs.target }}
    - name: Push new tag
      run: git push origin ${{ github.event.inputs.major_version }} --force
      
go自动构建发布
GoReleaser Pro：https://nsddd.top/zh/posts/go-release-tools/ 和 https://gitea.com/gitea/act_runner/src/branch/main/.gitea/workflows/release-tag.yml

# 日志生成
https://keepachangelog.com/zh-CN/1.1.0/
https://github.com/marketplace/actions/generate-changelog#outputs


这是个非常专业、实际的需求，下面我将以生产实践为你梳理一套完整的流程：**如何标准化 Commit 信息，并借助 GitHub Actions 自动生成高质量的 CHANGELOG，用于 `softprops/action-gh-release@v2` 展示变更内容**。

github日志生成+发布仓库

name: Conventional Changelog Action id: changelog uses: TriPSs/conventional-changelog-action@v5 with: github-token: ${{ secrets.github_token }} output-file: "false"
name: Create Release uses: actions/create-release@v1 if: ${{ steps.changelog.outputs.skipped == 'false' }} env: GITHUB_TOKEN: ${{ secrets.github_token }} with: tag_name: ${{ steps.changelog.outputs.tag }} release_name: ${{ steps.changelog.outputs.tag }} body: ${{ steps.changelog.outputs.clean_changelog }}

✅ 最佳实践目标

标准化 Commit Message 格式（title + body）
使用工具如 conventional-changelog 或 git-cliff 自动生成 CHANGELOG.md
自动将生成的 changelog 设置为 GitHub Release 的描述，配合 softprops/action-gh-release@v2

🧩 一、Commit Message 规范：Conventional Commits

Conventional Commit 是业界广泛使用的提交信息格式，自动语义化生成版本和变更日志。

✅ 格式：

<type>(optional scope): <description>

[optional body]

[optional footer(s)]

🔧 常用 `type` 列表：

类型	含义
`feat`	新功能
`fix`	修复 bug
`chore`	构建过程或辅助工具变动
`docs`	仅文档变更
`style`	空格、格式、缺少分号等无意义变动
`refactor`	重构，非修复或功能添加
`perf`	性能优化
`test`	增加测试或测试相关变更
`ci`	与 CI/CD 相关的改动

✅ 示例：

feat(auth): add JWT login support

- 用户登录接口增加 JWT 返回
- 新增 `/api/v1/token` 接口

BREAKING CHANGE: `/api/v1/login` 返回结构发生变化

🛠️ 二、推荐工具：`conventional-changelog` or `git-cliff`

🚀 推荐：使用 `git-cliff`

特点：

更现代、配置简单
支持 emoji、高级分组
支持 tag 比对差异、PR 信息、author 等

📄 三、GitHub Actions 集成流程（用 `git-cliff`）

✅ 1. 安装 `git-cliff`：

- name: Install git-cliff
  run: |
    curl -sSL https://github.com/orhun/git-cliff/releases/download/v1.3.0/git-cliff-x86_64-unknown-linux-musl.tar.gz | tar -xz
    sudo mv git-cliff /usr/local/bin

✅ 2. 配置 `.gitcliff.toml`（放仓库根目录）：

[changelog]
header = "# 📦 Changelog\n\n"
body = """
{% for group, commits in commits | group_by(attribute="group") %}
### {{ group | upper_first }}
{% for commit in commits %}
- {{ commit.message | trim }} ({{ commit.id | truncate(length=7) }})
{% endfor %}
{% endfor %}
"""
footer = "\n*Generated on {{ timestamp | date(format='%Y-%m-%d') }}*"

[git]
conventional_commits = true
filter_commits = true
tag_pattern = "v[0-9]*"

📦 四、完整 GitHub Actions：生成 changelog + 发布 release

name: Release

on:
  push:
    tags:
      - "v*"

jobs:
  release:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install git-cliff
        run: |
          curl -sSL https://github.com/orhun/git-cliff/releases/download/v1.3.0/git-cliff-x86_64-unknown-linux-musl.tar.gz | tar -xz
          sudo mv git-cliff /usr/local/bin          

      - name: Generate CHANGELOG
        id: changelog
        run: |
          git fetch --tags
          git-cliff -t ${{ github.ref_name }} > CHANGELOG.md
          echo "CHANGELOG<<EOF" >> $GITHUB_OUTPUT
          cat CHANGELOG.md >> $GITHUB_OUTPUT
          echo "EOF" >> $GITHUB_OUTPUT          

      - name: Create GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          tag_name: ${{ github.ref_name }}
          name: Release ${{ github.ref_name }}
          body: ${{ steps.changelog.outputs.CHANGELOG }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

✅ 最终效果

Git 提交统一：feat:、fix: 等规范命名
CHANGELOG.md 自动生成：包含分组、短 ID、日期
GitHub Release 自动发布：含详细变更描述

🎯 建议团队落地操作

启用 Commit 校验钩子（如 husky + commitlint）
PR 合并统一走 squash + rebase 模式
Tag 发布统一通过 Actions 管理
对开发者编写 commit message 做简单规范培训

💬 如果你想要：

自动创建 tag（如 release-$(date +%Y%m%d)）+ changelog + Release
在 monorepo 多模块项目中按模块生成 changelog
把 changelog 自动更新到 CHANGELOG.md 文件

我可以帮你扩展这套 CI 流程。是否继续？

很好！你选择使用：

✅ janheinrichmerker/action-github-changelog-generator@v2.3

这个 Action 封装了 GitHub 官方的 github-changelog-generator，可以根据 GitHub 的 Issue、PR、标签、Milestone 自动生成漂亮的 CHANGELOG.md。

🧩 你当前需求是：

自动生成 changelog，提取本次 tag 对应的变更内容，用于传给 softprops/action-gh-release@v2 的 body 参数显示发布详情 ✅。

✅ 实现流程概览

步骤	工具
1. 提交 tag（如 `v1.2.3`）	手动或自动打 tag
2. 生成完整 `CHANGELOG.md`	`janheinrichmerker/action-github-changelog-generator@v2.3`
3. 提取本 tag 部分内容	Shell 脚本 + `awk` / `sed` / `perl`
4. 创建 GitHub Release	`softprops/action-gh-release@v2`

📄 完整 Workflow 示例：生成并提取当前版本 Changelog

name: Release with Changelog

on:
  push:
    tags:
      - "v*"

jobs:
  release:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Generate full changelog
        uses: janheinrichmerker/action-github-changelog-generator@v2.3
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          user: ${{ github.repository_owner }}
          project: ${{ github.event.repository.name }}
          output: CHANGELOG.md

      - name: Extract current version changelog
        id: extract
        run: |
          TAG_NAME="${GITHUB_REF##*/}"  # v1.2.3
          
          # 用 awk 截取当前 tag 的 section 到下一个 tag（或文件末尾）
          awk -v tag="## ${TAG_NAME}" '
            $0 ~ tag {flag=1; next}
            /^## / && flag {exit}
            flag {print}
          ' CHANGELOG.md > current-changelog.md

          echo "Extracted changelog:"
          cat current-changelog.md

          # 保存到 output 供后续 step 使用
          echo "BODY<<EOF" >> $GITHUB_OUTPUT
          cat current-changelog.md >> $GITHUB_OUTPUT
          echo "EOF" >> $GITHUB_OUTPUT          

      - name: Publish GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          tag_name: ${{ github.ref_name }}
          name: Release ${{ github.ref_name }}
          body: ${{ steps.extract.outputs.BODY }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

✅ 效果示例（`CHANGELOG.md` 结构）

# Changelog

## v1.2.3 (2025-07-27)

### Added
- ✨ Add user login feature (#42)

### Fixed
- 🐛 Fix crash on startup (#45)

## v1.2.2 (2025-07-15)

...

提取结果 current-changelog.md 内容将是 v1.2.3 的 block（不含标题）：

### Added
- ✨ Add user login feature (#42)

### Fixed
- 🐛 Fix crash on startup (#45)

🧠 注意事项

项目	说明
`awk` 提取 tag 区块	一定要确保 tag 格式为 `## v1.2.3`
不含 `## v1.2.3` 行	因为 Release title 会单独写 `Release v1.2.3`
如果没有下一个 tag，会提取到末尾	`awk` 会自动停在下一个 `##` 开头或文件末尾
PR 标题必须规范	推荐标准化，如 `feat(xxx): ...` 更清晰

✨ 如果你希望进一步增强：

功能	实现方式
自动写入 `CHANGELOG.md`	`git add && commit`
删除旧 changelog 再生成	`rm -f CHANGELOG.md`
nightly 版本支持	`release-nightly-YYYYMMDD` 自定义 tag
多语言 changelog（中英文）	改 `.erb` 模板或用 `git-cliff` 替代
PR message 模板与规范	可结合 `semantic-pull-requests` 检查格式

是否要我帮你补一份 commit + PR message 编写规范模板（Markdown）？这样你的项目协作成员都能自动生成正确格式的 changelog，不需要人工修改。

太好了！下面我将为你提供一份标准化的 Commit Message + PR Template 模板（Markdown 格式），适配自动化 Changelog 和 GitHub Release 的需求，广泛适用于企业项目协作。

✅ 1. `COMMIT_CONVENTION.md`：提交信息规范文档（建议放在项目根目录）

# ✅ Git Commit 提交信息规范

为了保证自动生成 CHANGELOG、自动发布版本，请遵循 **Conventional Commits** 格式：

## ✅ 格式规范

():

```

🔑 示例

feat(auth): 添加 JWT 登录支持

用户登录接口新增 token 返回
兼容老版 cookie 登录接口

BREAKING CHANGE: /api/v1/login 响应结构发生变化

🎯 type 类型说明

type	含义（用于分类）
feat	✨ 新功能
fix	🐛 修复 bug
docs	📚 仅文档修改
style	💅 代码格式（空格、分号等）
refactor	🔨 重构代码（无新增功能或修复）
perf	⚡️ 性能优化
test	✅ 增加/修改测试代码
chore	🧹 构建过程或工具变更
ci	⚙️ CI/CD 流程相关更改

✏️ scope（可选）

模块、功能或目录名称，例如：

auth
login
ui/button
api/user

🚨 Footer（可选）

BREAKING CHANGE: 声明破坏性变更
Closes #123 自动关闭关联 issue

🚫 不规范示例

update login
fix bug
modify something

请避免使用这些无语义的提交信息。


---

# ✅ 2. `.github/PULL_REQUEST_TEMPLATE.md`：PR 模板（自动弹出填写）

```markdown
## 📌 本次变更概述

<!-- 请简要说明本次改动内容，方便审核人理解 -->

- 新增功能/修复内容：
- 涉及模块：
- 是否有 breaking change（重大兼容性变更）：

---

## ✅ 类型

请勾选你本次提交的类型（多选）：

- [ ] feat（新增功能）
- [ ] fix（修复 bug）
- [ ] docs（仅文档修改）
- [ ] style（代码格式修改，无逻辑变更）
- [ ] refactor（重构，无功能变更）
- [ ] perf（性能优化）
- [ ] test（增加/修改测试）
- [ ] chore（构建流程/依赖/脚手架修改）
- [ ] ci（CI/CD 配置变更）

---

## 🔗 关联 issue 或需求单

例如：

- Fixes #123
- Related to #456

---

## 🧪 测试说明（如有）

- [ ] 已本地验证功能正常
- [ ] 已通过 CI 检查
- [ ] 无新增逻辑，无需测试

---

## 📎 其他备注（可选）

<!-- 如有需要，请填写其他备注信息 -->

🚀 配置方法

📁 项目结构建议：

.
├── COMMIT_CONVENTION.md
├── .github/
│   ├── PULL_REQUEST_TEMPLATE.md

✅ 启用 PR 模板功能

只需将 PULL_REQUEST_TEMPLATE.md 放入 .github/ 目录，GitHub 会自动识别并在新建 PR 时提示填写。

🔧 Bonus: 本地 commit message 检查（可选）

如果你想强制开发者本地提交前符合规范，可以引入以下工具：

工具	功能
`commitlint`	检查 commit message 格式
`husky`	Git Hook 工具，拦截不合规范提交

我可以帮你生成一套 husky + commitlint 配置脚本，只需一条命令初始化，是否需要？

✅ 总结

通过以上模板和规范：

所有提交信息具备一致结构（支持自动解析）
PR 审核人快速了解改动内容
Changelog 自动生成高质量文档
GitHub Release 页面完整展示变更

是否还需要：

✅ CHANGELOG.md 自动更新写入提交并 push
✅ git-cliff.toml 适配这些 commit 格式的配置文件
✅ semantic-release 风格自动打 tag + publish

欢迎继续补充需求，我可以为你生成一个一体化版本发布流水线。

🔍 简短回答：

❌ softprops/action-gh-release@v2 只能用于 GitHub，不支持 Gitea。

它底层依赖 GitHub 的 REST API（通过 GITHUB_TOKEN 环境变量），而 Gitea 虽然界面类似 GitHub，但 API 与权限模型不兼容，无法直接复用这个 Action。

✅ 为什么你看到“只打了 tag，没有发布内容”？

那是因为你目前只做了 git tag + git push --tags，这只会：

在 Gitea 上显示标签
❌ 不会创建 Release 页面（除非手动或调用 API）

✅ 正确做法：Gitea 上自动创建 Release 的两种方式

✅ 方式一：使用 Gitea 的官方 Release API（手动请求）

Gitea 提供了 Create Release 接口：

POST /repos/{owner}/{repo}/releases

请求体示例：

{
  "tag_name": "v1.2.3",
  "name": "Release v1.2.3",
  "body": "更新内容如下：\n- 新增功能\n- 修复 bug",
  "draft": false,
  "prerelease": false
}

你可以通过 GitHub Actions 的 curl 脚本发请求：

- name: Publish Gitea Release
  run: |
    curl -X POST "$GITEA_API_URL/repos/$OWNER/$REPO/releases" \
      -H "Authorization: token $GITEA_TOKEN" \
      -H "Content-Type: application/json" \
      -d @- <<EOF    
{
  "tag_name": "${{ github.ref_name }}",
  "name": "Release ${{ github.ref_name }}",
  "body": "更新内容：\n- 自动发布",
  "draft": false
}
EOF
  env:
    GITEA_API_URL: https://your.gitea.server/api/v1
    OWNER: your-username
    REPO: your-repo
    GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}

🚨 注意：你需要在 Gitea 上创建一个 访问 Token 并存入 GITEA_TOKEN Secrets。

✅ 方式二：使用社区版支持 Gitea 的 GitHub Actions（实验性）

有社区项目如 appleboy/gitea-release-action，它专门用于 Gitea：

- uses: appleboy/gitea-release-action@master
  with:
    base_url: https://your.gitea.server
    token: ${{ secrets.GITEA_TOKEN }}
    owner: your-username
    repo: your-repo
    tag: v1.2.3
    name: Release v1.2.3
    body: |
      - Feature 1
      - Bugfix 2      
    files: |
      ./dist/*.zip

🔐 如何生成 Gitea API Token？

登录 Gitea 账号
进入 Settings → Applications
创建 Personal Access Token
拷贝并存入 GitHub 项目 Secrets，如 GITEA_TOKEN

✅ 总结：Gitea 不支持 `softprops/action-gh-release`，你应该：

目标	推荐方案
在 Gitea 上自动创建 Release	使用 `curl` + Gitea REST API 或 `appleboy/gitea-release-action`
上传文件并附加 Release	`files:` 字段支持上传 zip、tar.gz 等构建产物
保留 changelog 作为描述内容	自动生成 changelog 再传给 `body:`

如果你希望我帮你封装一份 适配 Gitea 的完整发布流程 GitHub Actions 模板，支持：

自动生成 tag（日期/版本）
自动生成 changelog
上传产物并发布到 Gitea

我可以马上生成 YAML 文件，你只需要告诉我：

你的 Gitea 域名
是否需要上传文件到 Release（如 .zip 或 .tar.gz）
是否希望自动打 tag（如 release-YYYYMMDD）

是否继续？

✅ **可以！**你完全可以在 GitHub Actions 中：

使用 actions/checkout@v4 拉取当前仓库的代码
配置另一个 GitHub 仓库的身份认证和远程地址
将代码 push 到那个“另外的 GitHub 仓库”

🧩 场景应用举例

同步代码到一个“镜像仓库”（mirror）
自动把当前项目发布到“组织模板仓库”
提交构建产物或转换后的文件到另一个 repo 的分支（如 gh-pages）

✅ 实战示例：推送到另一个 GitHub 仓库

假设：

当前仓库为：origin/source-repo
目标仓库为：target-user/target-repo
你已有目标仓库的 GH_TARGET_TOKEN（推荐用 personal access token 设置为 secret）

✅ 工作流程 YAML（核心步骤）

name: Mirror to Another Repo

on:
  push:
    branches:
      - main

jobs:
  sync-to-target:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout current repo
        uses: actions/checkout@v4

      - name: Configure git
        run: |
          git config --global user.name "github-actions[bot]"
          git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"          

      - name: Push to another GitHub repo
        env:
          TARGET_REPO: target-user/target-repo
          TARGET_TOKEN: ${{ secrets.GH_TARGET_TOKEN }}
        run: |
          # 替换远程地址为目标仓库
          git remote add mirror https://x-access-token:${TARGET_TOKEN}@github.com/${TARGET_REPO}.git

          # 强制推送 main 分支
          git push mirror main --force

🔐 安全注意事项

设置项	建议说明
`GH_TARGET_TOKEN`	使用另一个仓库 owner 生成的 token（带 `repo` 权限）
目标仓库为空/已有	会直接覆盖目标分支（使用 `--force` 时）请谨慎
私有仓库同步	目标 repo 可是私有，只要 token 有权限即可

🔄 可选增强功能

目标	方法
只同步某个子目录	使用 sparse-checkout 或 `cp -r dir` 后 re-init
推送为特定分支（如 `gh-pages`）	`git push mirror HEAD:gh-pages`
构建后产物推送（如 `/dist`）	手动 `git init` + commit + push 到另 repo
自动创建 release 并上传文件	搭配 `softprops/action-gh-release@v2`

✅ 总结

操作项	是否支持	方法说明
拉取本仓库最新代码	✅	`actions/checkout@v4`
推送到另一个 GitHub 仓库	✅	设置远程地址 + token 推送
支持推送构建产物	✅	可以 push 到目标 repo 的分支
支持 push tag	✅	`git push mirror --tags`

如果你希望我根据你的实际场景（如同步哪个目录、推送哪个分支、构建产物自动 commit）定制一份完整工作流，只需告诉我目标 repo 和目标用途，我可以直接帮你生成。是否继续？

非常好，这是一个非常实用的需求场景：

✅ 在 GitHub Actions 中从当前仓库生成一个新 tag（如版本号或日期 tag），然后将代码 + tag 推送到另一个 GitHub 仓库（比如镜像仓库）

🧩 应用场景示例

自动构建发布版本 → 推送到“发布仓库”
文档仓库自动构建 → 推送带 tag 到另一个公开仓库
多组织协作，主仓库打 tag 后同步代码 + 标签到其他仓库

✅ 完整工作流（核心逻辑）

假设

当前仓库：you/source-repo
目标仓库：your-org/target-repo
你已有目标仓库的 token，存为 GH_TARGET_TOKEN secret
要创建的 tag 格式为：release-YYYYMMDD-HHmm

✅ GitHub Actions Workflow 示例

name: Tag and Mirror to Another Repo

on:
  workflow_dispatch:  # 手动触发（也可以改成 push、release 等）

jobs:
  tag-and-push:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source repo
        uses: actions/checkout@v4

      - name: Generate new tag
        id: tag
        run: |
          new_tag="release-$(date +'%Y%m%d-%H%M')"
          echo "NEW_TAG=$new_tag" >> $GITHUB_ENV
          echo "tag=$new_tag" >> $GITHUB_OUTPUT          

      - name: Create new git tag
        run: |
          git config --global user.name "github-actions[bot]"
          git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git tag $NEW_TAG          

      - name: Add remote for target repo and push code + tag
        env:
          TARGET_REPO: your-org/target-repo
          TOKEN: ${{ secrets.GH_TARGET_TOKEN }}
        run: |
          git remote add target https://x-access-token:${TOKEN}@github.com/${TARGET_REPO}.git
          
          # 推送代码和 tag 到目标仓库
          git push target HEAD:main --follow-tags
          git push target $NEW_TAG

🧪 效果说明

动作	说明
`git tag $NEW_TAG`	创建新的本地标签（如 `release-20250727-1730`）
`git push target $NEW_TAG`	推送该标签到目标仓库
`git push target HEAD:main`	将当前分支代码推送到目标仓库的 `main` 分支

✅ 可选增强（按需添加）

功能	示例方法
推送为其他分支（如 `release`）	`git push target HEAD:release`
生成 changelog 或标注到 tag 内容中	可用 `git-cliff`、`conventional-changelog` 生成信息
上传构建产物到目标仓库的 release	使用 GitHub API 或 `softprops/action-gh-release`
判断 tag 是否已存在，避免重复发布	用 `git tag	grep "$NEW_TAG"` 判断

✅ GITHUB_TOKEN vs PAT（Personal Access Token）

你不能用默认的 ${{ secrets.GITHUB_TOKEN }} 推送到另一个 repo
必须用另一个 repo 的 PAT（访问令牌），带有至少 repo 权限

🎯 总结

任务	是否可行	方法关键点
在当前仓库打 tag	✅	`git tag $NEW_TAG`
推送 tag 到另一个 GitHub 仓库	✅	`git push target $NEW_TAG`
同时推送代码和 tag	✅	`git push target HEAD:main --follow-tags`

如你还想同步：

🔄 只推某目录内容（如 /dist、/docs）
📁 推送为 gh-pages 或 release 分支
📦 推送 Release 附件（zip/tar）

我可以给你写一个增强版本。是否需要我继续定制？

好的，我们来定制一个更高级实战版 GitHub Actions 工作流，用于从当前仓库：

✅ 构建产物 → 推送到另一个 GitHub 仓库指定目录和分支（如 `release` 或 `gh-pages`），并打上自动生成的 tag。

🧭 你的需求拆解如下：

步骤	动作
✅ 构建产物	例如打包 `dist/` 或构建网站输出
✅ 创建版本 tag	如 `release-20250727-1810`
✅ 初始化目标 repo	初始化空 Git 仓库，复制构建产物进去
✅ 推送到目标仓库的指定分支	如 `gh-pages` 或 `release`
✅ 可选：生成 Release 页面	用目标 repo token + GitHub API 实现

✅ 示例场景设定（你可以修改）

当前仓库构建出：dist/ 目录
要推送到目标仓库：your-org/target-repo
推送分支：gh-pages
Tag 格式：release-YYYYMMDD-HHmm
目标仓库凭据保存在 secret：GH_TARGET_TOKEN

📄 GitHub Actions 工作流（生产级模板）

name: Build & Deploy to Target Repo

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source repo
        uses: actions/checkout@v4

      - name: Set up Node (如有构建)
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Build project
        run: |
          # 示例构建命令，你可以替换为实际的构建流程
          npm ci
          npm run build
          # 输出在 dist/          

      - name: Create new tag
        id: tag
        run: |
          NEW_TAG="release-$(date +'%Y%m%d-%H%M')"
          echo "NEW_TAG=$NEW_TAG" >> $GITHUB_ENV
          echo "tag=$NEW_TAG" >> $GITHUB_OUTPUT          

      - name: Push dist/ to target repo branch
        env:
          TARGET_REPO: your-org/target-repo
          TARGET_BRANCH: gh-pages
          TARGET_TOKEN: ${{ secrets.GH_TARGET_TOKEN }}
        run: |
          cd dist

          git init
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"

          git remote add origin https://x-access-token:${TARGET_TOKEN}@github.com/${TARGET_REPO}.git
          git checkout -b $TARGET_BRANCH

          # 提交构建产物
          git add .
          git commit -m "🚀 Deploy from source-repo@$GITHUB_SHA"

          # 创建 tag
          git tag $NEW_TAG

          # 强制推送分支和 tag
          git push origin $TARGET_BRANCH --force
          git push origin $NEW_TAG          

      - name: ✅ Done
        run: echo "✅ 已将 dist/ 推送到 ${TARGET_REPO}:${TARGET_BRANCH} 并创建 tag $NEW_TAG"

✅ 效果

dist/ 目录变成了目标仓库的 gh-pages 分支内容
创建了一个 tag，如 release-20250727-1810
可用于 GitHub Pages / 发布仓库 / 组件包仓库等

💡 可选增强

1. 推送 zip 文件到目标仓库的 Release 页面

你可以增加一个 job，用 softprops/action-gh-release 或 [GitHub API + curl] 将 dist.zip 作为 Release 附件上传（如果目标仓库也是 GitHub 的话）。

2. 使用 `rsync` 同步子目录内容（不是覆盖整个 repo）

适用于目标仓库已有部分内容，只想增量更新。

3. 支持多个目标仓库（配置 matrix）

strategy:
  matrix:
    repo: [your-org/repo1, your-org/repo2]

🧪 Debug & 测试建议

先用 workflow_dispatch 手动测试，观察构建和 push 日志
检查目标 repo 权限：token 必须对其拥有 write + push 权限
使用 git log --oneline 确认 tag 是否正常创建

📦 如果你需要我帮你：

改为 Python/Java 项目构建产物流程
同步到 Gitea、Gitee 或私有 GitLab 仓库
添加 Release Notes、生成 SHA256 文件、通知钉钉/飞书/Slack

我可以继续为你定制补充。是否需要？

29 KiB Raw Permalink Blame History Unescape Escape

github日志生成+发布仓库

✅ 最佳实践目标

🧩 一、Commit Message 规范：Conventional Commits

✅ 格式：

🔧 常用 type 列表：

✅ 示例：

🛠️ 二、推荐工具：conventional-changelog or git-cliff

🚀 推荐：使用 git-cliff

📄 三、GitHub Actions 集成流程（用 git-cliff）

✅ 1. 安装 git-cliff：

✅ 2. 配置 .gitcliff.toml（放仓库根目录）：

📦 四、完整 GitHub Actions：生成 changelog + 发布 release

✅ 最终效果

🎯 建议团队落地操作

💬 如果你想要：

🧩 你当前需求是：

✅ 实现流程概览

📄 完整 Workflow 示例：生成并提取当前版本 Changelog

✅ 效果示例（CHANGELOG.md 结构）

🧠 注意事项

✨ 如果你希望进一步增强：

✅ 1. COMMIT_CONVENTION.md：提交信息规范文档（建议放在项目根目录）

🔑 示例

🎯 type 类型说明

✏️ scope（可选）

🚨 Footer（可选）

🚫 不规范示例

🚀 配置方法

📁 项目结构建议：

✅ 启用 PR 模板功能

🔧 Bonus: 本地 commit message 检查（可选）

✅ 总结

✅ 为什么你看到“只打了 tag，没有发布内容”？

✅ 正确做法：Gitea 上自动创建 Release 的两种方式

✅ 方式一：使用 Gitea 的官方 Release API（手动请求）

✅ 方式二：使用社区版支持 Gitea 的 GitHub Actions（实验性）

🔐 如何生成 Gitea API Token？

✅ 总结：Gitea 不支持 softprops/action-gh-release，你应该：

🧩 场景应用举例

✅ 实战示例：推送到另一个 GitHub 仓库

假设：

✅ 工作流程 YAML（核心步骤）

🔐 安全注意事项

🔄 可选增强功能

✅ 总结

🧩 应用场景示例

✅ 完整工作流（核心逻辑）

假设

✅ GitHub Actions Workflow 示例

🧪 效果说明

✅ 可选增强（按需添加）

✅ GITHUB_TOKEN vs PAT（Personal Access Token）

🎯 总结

✅ 构建产物 → 推送到另一个 GitHub 仓库指定目录和分支（如 release 或 gh-pages），并打上自动生成的 tag。

🧭 你的需求拆解如下：

✅ 示例场景设定（你可以修改）

📄 GitHub Actions 工作流（生产级模板）

✅ 效果

💡 可选增强

1. 推送 zip 文件到目标仓库的 Release 页面

2. 使用 rsync 同步子目录内容（不是覆盖整个 repo）

3. 支持多个目标仓库（配置 matrix）

🧪 Debug & 测试建议

📦 如果你需要我帮你：

29 KiB

Raw Permalink Blame History

🔧 常用 `type` 列表：

🛠️ 二、推荐工具：`conventional-changelog` or `git-cliff`

🚀 推荐：使用 `git-cliff`

📄 三、GitHub Actions 集成流程（用 `git-cliff`）

✅ 1. 安装 `git-cliff`：

✅ 2. 配置 `.gitcliff.toml`（放仓库根目录）：

✅ 效果示例（`CHANGELOG.md` 结构）

✅ 1. `COMMIT_CONVENTION.md`：提交信息规范文档（建议放在项目根目录）

✅ 总结：Gitea 不支持 `softprops/action-gh-release`，你应该：

✅ 构建产物 → 推送到另一个 GitHub 仓库指定目录和分支（如 `release` 或 `gh-pages`），并打上自动生成的 tag。

2. 使用 `rsync` 同步子目录内容（不是覆盖整个 repo）