1053 lines
29 KiB
Markdown
1053 lines
29 KiB
Markdown
```
|
||
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 }}
|
||
|
||
# ✅ 最佳实践目标
|
||
|
||
1. **标准化 Commit Message 格式**（title + body）
|
||
2. 使用工具如 [`conventional-changelog`](https://github.com/conventional-changelog/conventional-changelog) 或 [`git-cliff`](https://github.com/orhun/git-cliff) 自动生成 `CHANGELOG.md`
|
||
3. 自动将生成的 changelog 设置为 GitHub Release 的描述，配合 `softprops/action-gh-release@v2`
|
||
|
||
---
|
||
|
||
## 🧩 一、Commit Message 规范：**Conventional Commits**
|
||
|
||
Conventional Commit 是业界广泛使用的提交信息格式，自动语义化生成版本和变更日志。
|
||
|
||
### ✅ 格式：
|
||
|
||
```text
|
||
<type>(optional scope): <description>
|
||
|
||
[optional body]
|
||
|
||
[optional footer(s)]
|
||
```
|
||
|
||
### 🔧 常用 `type` 列表：
|
||
|
||
| 类型 | 含义 |
|
||
| ---------- | ---------------- |
|
||
| `feat` | 新功能 |
|
||
| `fix` | 修复 bug |
|
||
| `chore` | 构建过程或辅助工具变动 |
|
||
| `docs` | 仅文档变更 |
|
||
| `style` | 空格、格式、缺少分号等无意义变动 |
|
||
| `refactor` | 重构，非修复或功能添加 |
|
||
| `perf` | 性能优化 |
|
||
| `test` | 增加测试或测试相关变更 |
|
||
| `ci` | 与 CI/CD 相关的改动 |
|
||
|
||
### ✅ 示例：
|
||
|
||
```text
|
||
feat(auth): add JWT login support
|
||
|
||
- 用户登录接口增加 JWT 返回
|
||
- 新增 `/api/v1/token` 接口
|
||
|
||
BREAKING CHANGE: `/api/v1/login` 返回结构发生变化
|
||
```
|
||
|
||
---
|
||
|
||
## 🛠️ 二、推荐工具：`conventional-changelog` or `git-cliff`
|
||
|
||
### 🚀 推荐：使用 [`git-cliff`](https://github.com/orhun/git-cliff)
|
||
|
||
特点：
|
||
|
||
* 更现代、配置简单
|
||
* 支持 emoji、高级分组
|
||
* 支持 tag 比对差异、PR 信息、author 等
|
||
|
||
---
|
||
|
||
## 📄 三、GitHub Actions 集成流程（用 `git-cliff`）
|
||
|
||
### ✅ 1. 安装 `git-cliff`：
|
||
|
||
```yaml
|
||
- 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`（放仓库根目录）：
|
||
|
||
```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
|
||
|
||
```yaml
|
||
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 自动发布**：含详细变更描述
|
||
|
||
---
|
||
|
||
## 🎯 建议团队落地操作
|
||
|
||
1. **启用 Commit 校验钩子**（如 husky + commitlint）
|
||
2. **PR 合并统一走 squash + rebase 模式**
|
||
3. **Tag 发布统一通过 Actions 管理**
|
||
4. **对开发者编写 commit message 做简单规范培训**
|
||
|
||
---
|
||
|
||
## 💬 如果你想要：
|
||
|
||
* 自动创建 tag（如 `release-$(date +%Y%m%d)`）+ changelog + Release
|
||
* 在 monorepo 多模块项目中按模块生成 changelog
|
||
* 把 changelog 自动更新到 `CHANGELOG.md` 文件
|
||
|
||
我可以帮你扩展这套 CI 流程。是否继续？
|
||
|
||
|
||
|
||
|
||
|
||
很好！你选择使用：
|
||
|
||
> ✅ [`janheinrichmerker/action-github-changelog-generator@v2.3`](https://github.com/janheinrichmerker/action-github-changelog-generator)
|
||
|
||
这个 Action 封装了 GitHub 官方的 [github-changelog-generator](https://github.com/github-changelog-generator/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
|
||
|
||
```yaml
|
||
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` 结构）
|
||
|
||
```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（不含标题）：
|
||
|
||
```md
|
||
### 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`：提交信息规范文档（建议放在项目根目录）
|
||
|
||
```markdown
|
||
# ✅ Git Commit 提交信息规范
|
||
|
||
为了保证自动生成 CHANGELOG、自动发布版本，请遵循 **Conventional Commits** 格式：
|
||
|
||
## ✅ 格式规范
|
||
|
||
```
|
||
|
||
<type>(<scope>): <subject>
|
||
|
||
<optional body>
|
||
|
||
<optional footer>
|
||
```
|
||
|
||
### 🔑 示例
|
||
|
||
```
|
||
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
|
||
|
||
---
|
||
|
||
## 🚫 不规范示例
|
||
|
||
```text
|
||
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 接口](https://try.gitea.io/api/swagger#/repository/repoCreateRelease)：
|
||
|
||
```
|
||
POST /repos/{owner}/{repo}/releases
|
||
```
|
||
|
||
请求体示例：
|
||
|
||
```json
|
||
{
|
||
"tag_name": "v1.2.3",
|
||
"name": "Release v1.2.3",
|
||
"body": "更新内容如下：\n- 新增功能\n- 修复 bug",
|
||
"draft": false,
|
||
"prerelease": false
|
||
}
|
||
```
|
||
|
||
你可以通过 GitHub Actions 的 `curl` 脚本发请求：
|
||
|
||
```yaml
|
||
- 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`](https://github.com/appleboy/gitea-release-action)，它专门用于 Gitea：
|
||
|
||
```yaml
|
||
- 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？
|
||
|
||
1. 登录 Gitea 账号
|
||
2. 进入 `Settings` → `Applications`
|
||
3. 创建 `Personal Access Token`
|
||
4. 拷贝并存入 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 文件，你只需要告诉我：
|
||
|
||
1. 你的 Gitea 域名
|
||
2. 是否需要上传文件到 Release（如 `.zip` 或 `.tar.gz`）
|
||
3. 是否希望自动打 tag（如 `release-YYYYMMDD`）
|
||
|
||
是否继续？
|
||
|
||
|
||
|
||
✅ \*\*可以！\*\*你完全可以在 GitHub Actions 中：
|
||
|
||
1. 使用 `actions/checkout@v4` 拉取当前仓库的代码
|
||
2. **配置另一个 GitHub 仓库的身份认证和远程地址**
|
||
3. **将代码 push 到那个“另外的 GitHub 仓库”**
|
||
|
||
---
|
||
|
||
## 🧩 场景应用举例
|
||
|
||
* 同步代码到一个“镜像仓库”（mirror）
|
||
* 自动把当前项目发布到“组织模板仓库”
|
||
* 提交构建产物或转换后的文件到另一个 repo 的分支（如 `gh-pages`）
|
||
|
||
---
|
||
|
||
## ✅ 实战示例：推送到另一个 GitHub 仓库
|
||
|
||
### 假设：
|
||
|
||
* 当前仓库为：`origin/source-repo`
|
||
* 目标仓库为：`target-user/target-repo`
|
||
* 你已有目标仓库的 `GH_TARGET_TOKEN`（推荐用 [personal access token](https://github.com/settings/tokens) 设置为 secret）
|
||
|
||
---
|
||
|
||
### ✅ 工作流程 YAML（核心步骤）
|
||
|
||
```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 示例
|
||
|
||
```yaml
|
||
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 工作流（生产级模板）
|
||
|
||
```yaml
|
||
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`](https://github.com/softprops/action-gh-release) 或 \[GitHub API + curl] 将 `dist.zip` 作为 Release 附件上传（如果目标仓库也是 GitHub 的话）。
|
||
|
||
---
|
||
|
||
### 2. 使用 `rsync` 同步子目录内容（不是覆盖整个 repo）
|
||
|
||
适用于目标仓库已有部分内容，只想增量更新。
|
||
|
||
---
|
||
|
||
### 3. 支持多个目标仓库（配置 matrix）
|
||
|
||
```yaml
|
||
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
|
||
|
||
我可以继续为你定制补充。是否需要？
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|