refactor: scope onboarding skill to app release flow
This commit is contained in:
xiaobing.wang
parent
0567364af5
commit
dd77f8da1f
@ -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` 或其他发布侧清单
|
||||
|
||||
## 安装
|
||||
|
||||
|
||||
@ -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/<app>/` 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/<app>/manifests/`。
|
||||
|
||||
## 当前 GitOps 仓库通常需要生成什么
|
||||
|
||||
只有在“首次接入当前 GitOps 仓库”或用户明确要求时，才生成或修复：
|
||||
|
||||
- `apps/<app-name>/application.yaml`
|
||||
- `bootstrap/projects/<app-name>-project.yaml`
|
||||
- `releases/<app-name>/metadata.yaml`
|
||||
- `releases/<app-name>/values.yaml`
|
||||
- `releases/<app-name>/manifests/secret.yaml`
|
||||
- `releases/<app-name>/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/<app-name>/application.yaml`
|
||||
- `releases/<app-name>/values.yaml`
|
||||
- `releases/<app-name>/metadata.yaml`
|
||||
- `releases/<app-name>/manifests/` 下由当前应用导出的发布结果
|
||||
|
||||
不要在这个 job 中加入集群部署逻辑。
|
||||
|
||||
@ -297,6 +282,8 @@ deploy/helm/<app-name>/
|
||||
- 如果用户暂时没有提供，不要造占位内容冒充可部署配置
|
||||
- 可以只保留结构，或暂不生成具体 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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user