Back to Details

gh-oss-release

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

OSS Release

OSS 发布

Batch release workflow for multiple OSS repositories using 
gh oss-watch releases
.
使用
gh oss-watch releases
在多个OSS仓库中批量执行发布的工作流。

Workflow

工作流

Step 1: Check Release Status

步骤1：检查发布状态

Run 
gh oss-watch releases
to identify repos with unreleased commits.
If all repos are up to date, report that and stop.
运行
gh oss-watch releases
识别存在未发布提交的仓库。
如果所有仓库均为最新状态，将进行报告并终止流程。

Step 2: Analyze Unreleased Commits

步骤2：分析未发布提交

For each repo needing a release, fetch commit messages since the last tag in parallel:
bash
gh api repos/<owner>/<repo>/compare/<last-tag>...HEAD --jq '[.commits[] | .commit.message | split("\n")[0]] | .[]'
为每个需要发布的仓库，并行获取从上一个标签到HEAD的提交信息：
bash
gh api repos/<owner>/<repo>/compare/<last-tag>...HEAD --jq '[.commits[] | .commit.message | split("\n")[0]] | .[]'

Step 3: Recommend Semver Bump

步骤3：推荐SemVer版本升级

Classify each commit's first line and recommend the highest applicable bump:
Commit patternBump
deps:
, 
deps-dev:
, 
ci:
, 
chore:
, maintenance-only		patch
feat:
, new functionality, non-breaking additions		minor
BREAKING CHANGE
, 
!:
suffix, API removals		major
If ALL commits are deps/ci/chore, recommend patch. If any commit adds a feature, recommend minor. If any commit has breaking changes, recommend major.
分类每个提交的第一行内容，推荐优先级最高的版本升级类型：
提交模式升级类型
deps:
、
deps-dev:
、
ci:
、
chore:
、仅维护性变更		patch
feat:
、新增功能、非破坏性新增内容		minor
BREAKING CHANGE
、
!:
后缀、API移除		major
如果所有提交均为依赖/CI/杂项变更，推荐patch。如果存在任何新增功能的提交，推荐minor。如果存在任何包含破坏性变更的提交，推荐major。

Step 4: Present Recommendations

步骤4：展示推荐内容

Present a table for user confirmation:
| Repo | Current | Recommended | Commits | Rationale |
|------|---------|-------------|---------|-----------|
| repo-name | v1.2.3 | v1.2.4 | 5 | All dependency bumps |
Use AskUserQuestion or wait for explicit user confirmation before proceeding.
为用户展示表格以确认：
| 仓库 | 当前版本 | 推荐版本 | 提交数量 | 理由 |
|------|---------|-------------|---------|-----------|
| repo-name | v1.2.3 | v1.2.4 | 5 | 所有变更均为依赖升级 |
在继续前，使用AskUserQuestion或等待用户明确确认。

Step 5: Create Releases

步骤5：创建Releases

After confirmation, create releases in parallel:
bash
gh release create <new-tag> --repo <owner>/<repo> --generate-notes
获得确认后，并行创建Releases：
bash
gh release create <new-tag> --repo <owner>/<repo> --generate-notes

Step 6: Verify

步骤6：验证

Run 
gh oss-watch releases
again to confirm all repos show "up to date".
再次运行
gh oss-watch releases
，确认所有仓库显示“up to date”。

Step 7: Update Homebrew Tap

步骤7：更新Homebrew Tap

After all releases are verified, update the homebrew-tap formulae:
bash
cd ~/ghq/github.com/jackchuka/homebrew-tap
git pull origin main
make update
Then commit with a message listing the updated versions (e.g., 
update: gql-ingest v3.1.6, slackcli v0.3.0
) and push:
bash
git add -A
git commit -m "<version summary>"
git push origin main
所有发布验证完成后，更新homebrew-tap公式：
bash
cd ~/ghq/github.com/jackchuka/homebrew-tap
git pull origin main
make update
随后提交包含更新版本列表的信息（例如：
update: gql-ingest v3.1.6, slackcli v0.3.0
）并推送：
bash
git add -A
git commit -m "<version summary>"
git push origin main

Important Notes

重要说明

  • Tag-triggered CI: Most repos have CI that triggers on tag push (goreleaser, gh-extension-precompile, npm publish). The 
    gh release create
    command creates the tag which triggers the CI build.
  • npm packages with tag-triggered workflows: These repos derive version from the git tag during CI — no package.json bump needed.
  • Parallel execution: Fetch commits and create releases in parallel across repos for speed.
  • Never force: Always confirm with user before creating any releases.
  • 标签触发的CI：大多数仓库都配置了在标签推送时触发的CI（goreleaser、gh-extension-precompile、npm publish）。
    gh release create
    命令会创建标签，进而触发CI构建。
  • 带有标签触发工作流的npm包：这些仓库在CI流程中从git标签获取版本号——无需修改package.json。
  • 并行执行：为提升效率，在多个仓库间并行获取提交信息和创建Releases。
  • 绝不强制操作：在创建任何Releases前必须获得用户明确确认。