diff --git a/README.md b/README.md index 20aae44..ec2f37d 100644 --- a/README.md +++ b/README.md @@ -16,14 +16,15 @@ - 给当前平台接入新项目 - 恢复 `.gitlab-ci.yml`、`deploy/`、Helm Chart、release bundle -- 修当前 GitOps 仓库中的 `Application`、`AppProject`、release 引用 -- 补齐当前平台的 GitOps 交付链路 +- 修当前平台的发版链路 +- 让应用仓库在发版时推送自己的 release 结果 不适合处理： - 通用 GitLab CI 改造 - 通用 Helm Chart 编写 - 未指向当前平台常量的通用 GitOps / Argo CD 任务 +- 修改 GitOps 仓库中的 `Application`、`AppProject` 或其他发布侧清单 ## 安装 diff --git a/gitops-app-onboarding/SKILL.md b/gitops-app-onboarding/SKILL.md index 1c3fc83..f6b30fb 100644 --- a/gitops-app-onboarding/SKILL.md +++ b/gitops-app-onboarding/SKILL.md @@ -1,6 +1,6 @@ --- name: gitops-app-onboarding -description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适用于 `deploy.baizhi.cloud`、`registry.baizhi.cloud`、GitLab + Argo CD 这套固定交付模型。只要用户提到“给当前平台接入新项目”“恢复 .gitlab-ci.yml / deploy 目录”“修当前 GitOps 仓库里的 Application / AppProject / release 引用”“补齐当前平台的 Helm chart / release bundle / GitOps 交付链路”，就应优先使用这个 skill；如果只是通用 CI、通用 Helm 或通用 GitOps 任务而未指向当前平台，不应触发。 +description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适用于 `deploy.baizhi.cloud`、`registry.baizhi.cloud`、GitLab + Argo CD 这套固定交付模型。只要用户提到“给当前平台接入新项目”“恢复 .gitlab-ci.yml / deploy 目录”“补齐当前平台的 Helm chart / release bundle”“修当前平台的发版链路”“让应用仓库在发版时推送自己的 release 结果”，就应优先使用这个 skill；如果只是通用 CI、通用 Helm 或通用 GitOps 任务而未指向当前平台，不应触发。 --- # GitOps 项目接入 Skill @@ -14,7 +14,7 @@ description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适 - 为应用仓库补齐或恢复 `.gitlab-ci.yml` - 生成或修复 `deploy/helm//` Chart - 生成或修复 `deploy/release/` release bundle -- 在需要时补当前 GitOps 仓库中的 `Application`、`AppProject` 与发布结果 +- 在发版链路中将当前应用自己的 release 结果推送到固定 GitOps 仓库 ## 平台固定常量 @@ -42,15 +42,13 @@ description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适 开始改代码前，按下面顺序建立上下文： -1. 先读当前 GitOps 仓库 `README.md` -2. 再读目标应用仓库 `README.md` -3. 再读 Dockerfile、包管理文件、构建脚本、现有 deploy 文件 -4. 如果用户给了额外设计文档，一并读取 +1. 先读目标应用仓库 `README.md` +2. 再读 Dockerfile、包管理文件、构建脚本、现有 deploy 文件 +3. 如果用户给了额外设计文档，一并读取 判断规则： - 目标应用仓库自己的 `README.md` 是应用运行架构的真相来源 -- 当前 GitOps 仓库 `README.md` 说明平台目录职责和安装入口 - 本 skill 定义平台接入流程、约束和执行重点 - 如果应用 README 与平台约定冲突，优先识别是“应用设计差异”还是“平台硬约束” - 如果冲突会直接改变最终实现且无法安全推断，再问用户；否则优先按已有代码和文档做最小偏差实现 @@ -70,11 +68,14 @@ description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适 先区分任务属于哪一种： -1. 只修应用仓库：仅修改应用仓库中的 CI、Chart、release 模板 -2. 首次接入当前 GitOps 仓库：除应用仓库外，还要补当前 GitOps 仓库中的发布文件 -3. 只修当前 GitOps 仓库：仅改 GitOps 侧引用与发布结果 +1. 补齐或修复应用仓库中的 CI、Chart、release 模板 +2. 修复应用仓库中的发版链路，使其在发版时推送当前应用自己的 release 结果 -如果用户只要求修应用仓库，不要擅自修改当前 GitOps 仓库。 +边界约束： + +- 本 skill 只处理应用仓库侧接入 +- 不读取、不判断、不修改 GitOps 仓库中的 `Application`、`AppProject` 或其他发布侧清单 +- 对 GitOps 的唯一动作，是在应用仓库 CI 中推送当前应用自己的 release 结果或版本引用 ## 交付模型 @@ -115,22 +116,6 @@ description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适 如果应用还有不适合放进 Chart 的静态清单，可以在后续发布结果中导出到当前 GitOps 仓库的 `releases//manifests/`。 -## 当前 GitOps 仓库通常需要生成什么 - -只有在“首次接入当前 GitOps 仓库”或用户明确要求时，才生成或修复： - -- `apps//application.yaml` -- `bootstrap/projects/-project.yaml` -- `releases//metadata.yaml` -- `releases//values.yaml` -- `releases//manifests/secret.yaml` -- `releases//manifests/kustomization.yaml` -- 其他确有必要的静态发布清单 - -如需建新应用骨架，优先执行或仿照 `scripts/new-app.sh`，不要脱离现有目录结构重新发明。 - -当前 GitOps 仓库保存的是 Argo 可消费的发布结果，不保存应用 Chart 模板源码。 - ## GitLab CI 规则 ### stages @@ -197,14 +182,14 @@ test job 应运行在分支和 MR 上，并执行目标项目自己的标准测 这个 job 必须： - 克隆 `https://${GITEA_USER}:${GITEA_TOKEN}@deploy.baizhi.cloud/gitops-admin/argodeploy.git` -- 只更新目标应用在当前 GitOps 仓库中的版本引用 +- 只同步当前应用自己的 release 结果或版本引用 - 提交并推送到 `main` 通常需要更新： -- `apps//application.yaml` - `releases//values.yaml` - `releases//metadata.yaml` +- `releases//manifests/` 下由当前应用导出的发布结果 不要在这个 job 中加入集群部署逻辑。 @@ -297,6 +282,8 @@ deploy/helm// - 如果用户暂时没有提供，不要造占位内容冒充可部署配置 - 可以只保留结构，或暂不生成具体 secret 内容，但必须在最终输出中明确警告缺失项与影响 +release bundle 只负责导出当前应用自己的发布结果，不负责维护 GitOps 仓库中的其他对象。 + ## 平台共享配置契约 `shared/` 目录只放平台级共享配置。 @@ -354,13 +341,12 @@ shared 边界： 建议按下面顺序推进： 1. 读取应用 README 与构建文件，梳理组件和暴露模型 -2. 判断任务范围是应用仓库、当前 GitOps 仓库，还是两者都要改 +2. 判断任务是补齐应用仓库接入，还是修复发版链路 3. 生成或修复 `.gitlab-ci.yml` 4. 生成或修复 Chart 与 values 5. 生成或修复 release bundle -6. 如任务需要，再补当前 GitOps 仓库中的 `Application` 与发布结果 -7. 完成非阻塞工作后，再处理可选私有接入提问 -8. 自检并在最终输出中说明风险点 +6. 完成非阻塞工作后，再处理可选私有接入提问 +7. 自检并在最终输出中说明风险点 ## 自检要求 @@ -373,7 +359,7 @@ shared 边界： 至少确认： - 应用仓库不再缺少接入文件 -- `.gitlab-ci.yml` 包含 test、镜像构建、chart 发布、GitOps 仓库更新逻辑 +- `.gitlab-ci.yml` 包含 test、镜像构建、chart 发布、release 结果同步逻辑 - release values 指向 `registry.baizhi.cloud` - GitOps 仓库更新 job 指向 `https://deploy.baizhi.cloud/gitops-admin/argodeploy.git` - CI 中没有直接调用 Argo