From d4f794b4d65c6a644b0cbe9e657beb83f1ff91a3 Mon Sep 17 00:00:00 2001 From: tianma-if Date: Fri, 24 Jul 2026 00:39:49 +0800 Subject: [PATCH] docs: codify release workflow --- AGENTS.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 958bb9e7..085150b2 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -36,6 +36,30 @@ Release 以上一个实际发布的正式 Release 为基线，审计完整提交 每个正式 Release 必须附带可安装的 Android APK。APK 文件名统一使用 `edgeever-android-vX.Y.Z-.apk`，例如 `edgeever-android-v0.4.14-arm64-v8a.apk`。GitHub APK 默认仅构建 `arm64-v8a`；只有出现明确兼容需求时才额外提供其他 ABI，Play AAB 仍保留全部架构。若完整变更区间影响移动端代码、其共享依赖、原生配置或 APK 构建，则从本次发布提交重新构建生产签名 APK；否则可复用最近的兼容 APK，并在正文中注明来源 Release。发布前验证 APK 版本、签名、SHA-256 及下载可用性。 +### Release 固化流程 + +执行“提交、推送并发布”时，必须按以下顺序操作： + +1. 在 `main` 上检查 `git status --short --branch` 和完整 diff。无关的未提交修改不得混入发布；需要继续保留的工作区修改应使用可恢复的 `git stash` 暂存，发布完成后恢复。 +2. 查询远端最新正式 Release 与标签，使用上一个实际 Release 作为变更审计基线；不得以孤立标签或仅存在于本地的标签作为基线。 +3. 确定下一个 SemVer 版本。同步更新根目录 `package.json`；若发布包含移动端代码或 APK，则同步更新 `apps/mobile/app.json` 的 `expo.version`，并递增 `android.versionCode`。 +4. 为功能或修复关联的 Issue 添加合适 Label（通常为 `enhancement` 或 `bug`），然后提交全部本次发布改动。提交后先推送 `main`，确认远端提交可见。 +5. 从即将发布的提交执行验证。至少完成相关类型检查、测试和 Web 构建；移动端变更必须执行 `bun run build:android:apk:local`，不得用工作区其他未提交改动构建 APK。 +6. 验证 APK 的 `versionName`、`versionCode`、包名、生产签名、目标 ABI、SHA-256 和文件大小。将产物重命名为 `edgeever-android-vX.Y.Z-arm64-v8a.apk`，并确保只上传该版本产物。 +7. 创建标签并推送标签，标签必须指向已验证的 `main` 提交；随后创建非 Draft、非 Prerelease 的 GitHub Release，上传 APK，并在发布后确认 Release、标签、附件状态和下载链接均可用。 +8. Release 正文使用英文，必须包含用户可感知的变化、关联 Issue 和实际验证结果；发布完成后将已完成的 Issue 回链到 Release 并关闭。 + +推荐的移动端发布验证命令： + +```sh +bun run typecheck +bun run typecheck:mobile +bun run build:web +bun run build:android:apk:local +``` + +生产签名环境文件和密钥必须位于仓库外（默认使用 `~/.config/edgeever/android/signing.env`），不得写入仓库、Release 正文或日志。 + ## Cloudflare 自动部署约束 当用户要求根据 GitHub 项目链接将本项目安装部署到 Cloudflare 时，必须先完整阅读并严格按照 `docs/agent-deploy-cloudflare.md` 执行。该文档是此部署流程的唯一操作规范；不要在本文件重复维护部署命令、密码配置或 Workers Builds 步骤。