ci: tag-driven release with tagpr + promote-stable

[neilkuan]

變更說明

改用 tagpr 自動化 release 流程，並保留 promote-stable 機制確保 stable image 跟 pre-release 是同一個 artifact。

核心原則：測過什麼就發什麼 (what you tested is what you ship)

之前 vs 之後

	之前	之後
Release 觸發	手動打 tag（beta + stable 兩階段）	tagpr 自動打 tag（merge Release PR 即 release）
版本管理	手動維護，Cargo.toml / Chart.yaml 不同步	tagpr 自動同步 Cargo.toml + Chart.yaml version/appVersion
CHANGELOG	無	tagpr 自動產生
Pre-release	beta tag 觸發完整 build	手動打 tag（e.g. v0.7.0-rc.1），完整 build
Stable release	也重新 build（跟 beta 不同 artifact）	promote pre-release image（re-tag，不 rebuild，同一個 artifact）
Promote 方式	用 commit SHA 找 image（必須同 commit）	用 git tag 找最新 pre-release image（不同 commit 也能 promote）
Image 保證	beta ≠ stable	pre-release = stable（同一個 image）

改動檔案

檔案	變更
.github/workflows/tagpr.yml	新增 — push to main 觸發 tagpr，GitHub App token（確保 tag push 觸發 build.yml）
.github/workflows/build.yml	兩條路徑：pre-release 完整 build / stable promote（用 version tag 找 pre-release image，re-tag）
.github/workflows/release.yml	移除重複 OCI push，保留 chart-releaser + install instructions
.tagpr	新增 — versionFile 同步 Cargo.toml + Chart.yaml，postVersionCommand 更新 appVersion
Cargo.toml	version 0.1.0 → 0.6.0（對齊 Chart.yaml）
charts/openab/Chart.yaml	version 0.6.1-beta.1 → 0.6.0，appVersion 從 git SHA 改為 semver
RELEASING.md	完整重寫，含 pre-release → stable 流程圖

Release Flow

Step 1: PR merge to main → tagpr 開 Release PR
        (更新 Cargo.toml + Chart.yaml + CHANGELOG)

Step 2: 打 pre-release tag → 完整 build → 測試
        git tag v0.7.0-rc.1 && git push origin v0.7.0-rc.1
        → build 4 images × 2 platforms
        → helm chart push OCI

Step 3: 測試通過 → merge Release PR
        → tagpr 打 v0.7.0 + GitHub Release
        → promote-stable: 找到 v0.7.0-rc.1 image → re-tag 為 0.7.0 / 0.7 / latest
        → helm chart push OCI

Step 4: release.yml 自動觸發
        → chart-releaser 更新 GitHub Pages index
        → 附加 install instructions

build.yml Job DAG

resolve-tag ← 驗證 tag 格式 + 解析 version / is_prerelease
    │
    ├─ is_prerelease=true ──► build-image (8 parallel: 4 variants × 2 platforms)
    │                             │
    │                             ▼
    │                         merge-manifests (tags: <sha> + version)
    │                             │
    │                             └──────────┐
    │                                        ▼
    └─ is_prerelease=false ─► promote-stable ──► release-chart (helm push OCI)
                              (git tag -l v0.7.0-*
                               → find latest rc
                               → verify image exists
                               → re-tag to stable)

Image Tags

Tag	Stable (v0.7.0)	Pre-release (v0.7.0-rc.1)
<sha>	v (from pre-release)	v
0.7.0 / 0.7.0-rc.1	v	v
0.7	v	x
latest	v	x

Version 同步（tagpr 自動處理）

檔案	欄位	更新方式
Cargo.toml	version	tagpr 內建 (versionFile)
charts/openab/Chart.yaml	version	tagpr 內建 (versionFile)
charts/openab/Chart.yaml	appVersion	postVersionCommand

GitHub Releases

Release	Tag	內容
tagpr	v0.7.0	CHANGELOG
chart-releaser	openab-0.7.0	Version Info + Installation instructions

限制

• Stable 必須先有 pre-release：promote-stable 查找 v{version}-* tag，找不到就失敗
• promote 用 version tag 找 image：不依賴 commit SHA，pre-release 和 stable 可在不同 commit
• 外部用戶不會裝到 pre-release：helm install 預設只拿 stable，pre-release 需明確 --version

[the3mi]

Code Review: tagpr + promote-stable PR

Logic Test Results ✅

Tested the core flow — tag validation, pre-release detection, and promote-stable tag lookup all work correctly.

⚠️ One Issue Found: appVersion in postVersionCommand

.tagpr

When TAGPR_NEXT_VERSION=0.7.0 (stable), appVersion gets set to 0.7.0, but the promoted stable image was actually built from 0.7.0-rc.2.

Result: users see appVersion: 0.7.0 but the binary is from the rc build.

Suggested fix: Set appVersion to the actual pre-release tag that was promoted.

✅ Design Looks Good

• promote-stable using git tag to find image (cross-commit promote) ✅
• DAG split between pre-release build and stable promote ✅
• versionFile sync across Cargo.toml + Chart.yaml ✅
• RELEASING.md is thorough ✅

Questions

1. APP_ID / APP_PRIVATE_KEY secrets — are these already set up in the repo? The workflow will fail without them.