polymech/zeroclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
chore/ci-docs-cleanup
zeroclaw/docs/i18n/vi/release-process.md
jordanthejet 541c357002 docs: rewrite CI docs for simplified 4-workflow system 
Remove all references to deleted workflows (ci-run.yml, CI Required Gate,
sec-audit, pub-docker-img, pub-release, pub-homebrew-core, pr-intake-checks,
pr-labeler, pr-auto-response, pr-check-stale, pr-check-status, pr-label-policy,
workflow-sanity, main-promotion-gate, sec-codeql, sec-vorpal, etc.).

Rewrite docs to match the current 4 workflows:
- ci.yml (PR checks: test + build)
- release.yml (automatic beta release on push to master)
- ci-full.yml (manual full cross-platform build matrix)
- promote-release.yml (manual stable release)

Files rewritten:
- docs/ci-map.md — complete rewrite for current workflows
- docs/release-process.md — new two-tier release model (beta/stable)
- .github/workflows/main-branch-flow.md — simplified delivery flows
- .github/workflows/README.md — removed deleted helper scripts

Files updated (stale CI references removed):
- docs/pr-workflow.md
- docs/reviewer-playbook.md
- CONTRIBUTING.md
- Vietnamese locale sync: docs/vi/ and docs/i18n/vi/ (ci-map, pr-workflow,
  release-process, reviewer-playbook)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-06 17:35:04 -05:00

3.6 KiB
Raw Permalink Blame History

Quy trình Release ZeroClaw

Runbook này định nghĩa quy trình release tiêu chuẩn của maintainer.

Cập nhật lần cuối: 2026-03-06.

Mục tiêu Release

  • Giữ release có thể dự đoán và lặp lại.
  • Chỉ publish từ code đã có trên master.
  • Xác minh artifact đa target trước khi publish.
  • Giữ cadence release đều đặn ngay cả khi khối lượng PR cao.

Mô hình Release

ZeroClaw sử dụng mô hình release hai tầng:

  • Beta release tự động — mỗi merge vào master kích hoạt beta pre-release (vX.Y.Z-beta.<run_number>).
  • Stable release thủ công — maintainer chạy Promote Release qua workflow dispatch để cắt phiên bản non-pre-release.

Hợp đồng Workflow

Tự động hóa release nằm trong:

  • .github/workflows/release.yml — beta release tự động khi push lên master
  • .github/workflows/promote-release.yml — stable release thủ công qua workflow dispatch

Beta Release (tự động)

  • Kích hoạt trên mỗi push lên master.
  • Tính version từ Cargo.toml: vX.Y.Z-beta.<run_number>.
  • Build ma trận 5 target (linux x86_64/aarch64, macOS x86_64/aarch64, Windows x86_64).
  • Publish GitHub pre-release với archives + SHA256SUMS.
  • Build và push Docker image đa nền tảng lên GHCR (beta + version tag).

Stable Release (thủ công)

  • Kích hoạt qua workflow_dispatch với input version (ví dụ 0.2.0).
  • Xác thực version khớp Cargo.toml và tag chưa tồn tại.
  • Build cùng ma trận 5 target như beta.
  • Publish GitHub stable release với archives + SHA256SUMS.
  • Build và push Docker image lên GHCR (latest + version tag).

Quy trình Maintainer

1) Kiểm tra trước trên master

  1. Đảm bảo CI xanh trên master mới nhất.
  2. Xác nhận không có incident ưu tiên cao hoặc regression đã biết đang mở.
  3. Xác nhận các beta release gần đây khỏe mạnh (kiểm tra trang GitHub Releases).

2) Tùy chọn: chạy CI Full Matrix

Nếu xác minh cross-compilation trước stable release:

  • Chạy CI Full Matrix thủ công (.github/workflows/ci-full.yml).
  • Xác nhận build thành công trên aarch64-unknown-linux-gnu, x86_64-apple-darwin và x86_64-pc-windows-msvc.

3) Tăng version trong Cargo.toml

  1. Tạo branch, cập nhật version trong Cargo.toml lên version mục tiêu.
  2. Mở PR, merge vào master.
  3. Merge kích hoạt beta release tự động.

4) Promote lên stable release

  1. Chạy workflow Promote Release thủ công:
    • version: version mục tiêu (ví dụ 0.2.0) — phải khớp Cargo.toml
  2. Workflow xác thực version, build tất cả target và publish.

5) Xác thực sau release

  1. Xác minh asset GitHub Release có thể tải.
  2. Xác minh GHCR tag cho version đã release.
  3. Xác minh đường dẫn cài đặt dựa trên release asset (ví dụ tải binary bootstrap).

Cadence Tiêu chuẩn

  • Release patch/minor: hàng tuần hoặc hai tuần một lần.
  • Sửa bảo mật khẩn cấp: ngoài lịch trình.
  • Beta release ship liên tục với mỗi merge.

Đường dẫn Khẩn cấp / Khôi phục

Nếu stable release thất bại:

  1. Sửa vấn đề trên master.
  2. Chạy lại Promote Release với cùng version (nếu tag chưa được tạo).
  3. Nếu tag đã tồn tại, tăng lên patch version tiếp theo.

Ghi chú Vận hành

  • Giữ thay đổi release nhỏ và có thể đảo ngược.
  • Ưu tiên một issue/checklist release cho mỗi version để handoff rõ ràng.
  • Tránh publish từ các branch tính năng tùy ý.