Chaos Mesh 贡献指南：从 Fork 到合入 PR 的完整开发流程

云原生运维测试可观测性【免费下载链接】chaos-meshA Chaos Engineering Platform for Kubernetes.项目地址https://gitcode.com/gh_mirrors/ch/chaos-mesh点击查看免费下载本文是 Chaos MeshA Chaos Engineering Platform for Kubernetes的贡献者开发指南以仓库根目录 CONTRIBUTING.md 为主线结合 Makefile、各子目录 README 与 PR 模板 展开覆盖 fork 与分支管理、按区域选择指南、聚焦测试与代码生成、make test/make check全量校验以及带 DCO 签名的 PR 提交流程。读完本文你将能独立完成一次从源码修改、生成代码、本地验证到提交 Pull Request 的完整贡献闭环。开始之前判断你的改动属于哪一类在动手写代码之前先明确改动的性质它决定了你应走的流程Bug 修复或小改进可以直接打开 Pull Request新功能、新混沌类型new chaos type、公共 API 变更或其他实质性工作应当先创建或评论 GitHub Issue让设计与所有权在实现之前达成一致避免大改动与既有维护方向冲突。一个 PR 应聚焦解决一个问题与本次贡献无关的改动应保留在工作树中不要混入同一 PR。设置你的 Fork贡献的第一步是 fork 仓库并建立与上游的同步关系git clone gitgithub.com:YOUR_GITHUB_USERNAME/chaos-mesh.git cd chaos-mesh git remote add upstream https://github.com/chaos-mesh/chaos-mesh.git git fetch upstream git switch --create BRANCH_NAME upstream/master要点分支必须从最新master创建upstream/master而不是从你自己的 fork 分支创建否则会带入陈旧提交每个 PR 只解决一个问题保持分支短小在开发过程中当需要与上游保持同步时定期git fetch upstream并 rebase 到upstream/master避免合并冲突堆积到 review 阶段。阅读与改动区域对应的指南Chaos Mesh 仓库较大先读离你要改的代码最近的文档比通读全部源码更高效。CONTRIBUTING.md 给出了如下区域到指南的映射路径均已转换为仓库根目录相对路径改动区域指南项目总览README.md控制器架构、reconcile 逻辑与混沌实现controllers/README.md可执行入口与仓库生成器cmd/README.mdHelm Chart 配置与开发helm/chaos-mesh/README.mdDashboard 前端ui/README.md集成测试test/integration_test/README.md各子目录内的 README 还包含更聚焦的设计与生命周期细节。例如 controllers/README.md 说明了控制器由 Uber Fx 通过controllers.Module组装并给出chaosimpl/、common/、schedule/、statuscheck/、multicluster/等目录的职责划分cmd/README.md 则解释了chaos-controller-manager、chaos-daemon、chaos-dashboard、watchmaker等入口的构建路径。在引入新抽象之前先遵循既有的包边界与模式。修改并验证你的改动开发期跑最聚焦的测试实现改动应当与测试一同提交。开发过程中优先运行改动区域 README 里描述的最窄范围的测试、构建、lint 或 Helm 渲染命令而不是反复跑全仓库检查。对于聚焦的 Go 改动在拥有该包的模块下运行测试go test ./path/to/package以 controllers/README.md 给出的示例为例go test ./controllers/common/... go test ./controllers/schedule/... go test ./controllers/statuscheck/... go test ./controllers/multicluster/... go test ./controllers/chaosimpl/podchaos/...注意部分测试套件依赖 controller-runtime envtest 的 API Server/etcd 资源本地缺少这些资源时应在仓库的开发环境中运行对应 Makefile 中的images/dev-env/.dockerbuilt依赖见 Makefile。不要直接编辑生成文件Chaos Mesh 有大量生成代码直接手改会被后续生成覆盖。正确的做法是改源头跑生成器。例如API 或 CRD 变更后运行make generate从 Makefile 可以看到generate是一个组合目标它串联了manifests/crd.yaml用 controller-gen 生成config/crd/bases/下的 CRD 清单并同步到helm/chaos-mesh/crds/Makefilegenerate-deepcopy用 controller-gen 生成api/v1alpha1/zz_generated.deepcopy.goMakefilegenerate-client依次调用client-gen、lister-gen、informer-gen产出pkg/client/versioned、pkg/client/listers、pkg/client/informersMakefilechaos-build运行bin/chaos-builder扫描api/v1alpha1上的chaos-mesh:*标记生成api/v1alpha1/zz_generated.chaosmesh.go、workflow/schedule 注册文件以及前端类型映射ui/app/src/api/zz_generated.frontend.chaos-mesh.tsMakefilecmd/README.mdswagger_spec用swag init从cmd/chaos-dashboard/main.go生成 OpenAPI/Swagger 文档到pkg/dashboard/swaggerdocs/Makefile。以新增一个顶层混沌类型为例controllers/README.md 给出了完整步骤在api/v1alpha1/定义并打标记 → 在chaosimpl/下实现单目标Apply/Recover→ 提供ChaosImplPair并纳入chaosimpl.AllImpl→ 运行make generate并审查生成产物。生成类改动的检查闭环可参考 cmd/README.md修改cmd/generate-makefile/中的 recipe 后运行go test ./cmd/generate-makefile/...、make generate-makefile并git diff三个生成的 Makefile。最终验证广域检查当改动确实需要、或作为提交前的最终校验时运行make test make check这两个目标可能重新生成或格式化已跟踪文件甚至构建容器化开发环境。运行结束后务必检查git status git diff只保留与本次贡献相关的改动。从 Makefile 可以看到check由generate vet lint fmt tidy helm-values-schema组成包含go vet、revive lint配置见 revive.toml、goimports 格式化与go mod tidy一致性检查test则先启用 failpoint 桩再以-p 1串行执行全部包的单测并产出覆盖率Makefile。另外注意不要在没有合适的可复用 Kubernetes 集群、且改动并不需要的情况下运行端到端或故障注入测试。E2E 测试通过make e2e在当前集群中运行Makefile集成测试则通过 test/integration_test/run.sh 按用例执行前置条件是已用 Helm 安装 Chaos Meshtest/integration_test/README.md。提交 Pull Request提交前检查git status --short git diff --check git add CHANGED_FILES git commit --signoff git push --set-upstream origin BRANCH_NAMEgit diff --check用于发现空白字符等格式问题只暂存打算提交的文件不要把无关改动带进 PR每个 commit 都要--signoff以满足 DCODeveloper Certificate of Origin要求。仓库 CI 中配置了 dummy-dco.yml 之类的 DCO 检查若 DCO 检查失败可参考 PR 模板 用git commit --amend --signoff或git rebase -i HEAD~n重新签名后git push --force。Commit Message 与 PR 标题Commit message 与 PR 标题遵循 Conventional Commits 规范如feat: ...、fix: ...、docs: ...等带类型前缀的格式。填写 PR 模板打开 .github/pull_request_template.md 并按模板填写What problem does this PR solve简述解决的问题可close #issue_number关联 IssueWhats changed and how does it work说明改动方式可引用已有的 proposal 或设计文档Related changes勾选是否需要同步更新网站文档或 UI 界面Cherry-pick to release branches如需要勾选要回移的发布分支如release-2.8、release-2.7ChecklistCHANGELOG更新 CHANGELOG.md 或给 PR 打上no-need-update-changelog标签仓库 CI 的 must_update_changelog.yml 会据此检查Tests在 Unit test / E2E test / Manual test 中至少勾选一项并描述验证方式Side effects如有破坏性兼容变更需勾选标注。评审阶段评审期间向同一分支推送跟进提交follow-up commits不要另开分支必要时用git fetch upstream rebase 保持分支与upstream/master同步避免在 PR 中混入与主题无关的清理改动。获取帮助Bug 与功能讨论使用 GitHub Issues更广泛的开发问题参见 README.md 中列出的社区渠道包括 CNCF Slack 的#project-chaos-mesh频道以及每月第四个周四的社区月度会议、隔周二举行的开发会议深入背景CONTRIBUTING.md 还推荐了 Chaos Mesh developer guide官方站点文档用于了解混沌类型开发与开发环境搭建的更多背景。小结一次完整的 Chaos Mesh 贡献流程可以概括为在 Issue 中确认设计与归属 → fork 并基于upstream/master创建分支 → 阅读对应区域 README → 实现改动并同步补充测试 → 用最窄测试迭代、用make generate刷新生成代码、在合适时机跑make test/make check全量校验 → 检查git diff只保留相关改动 → 以--signoff提交、按 Conventional Commits 与 PR 模板发起 Pull Request。把握生成代码改源头、测试从窄到宽、PR 聚焦单一问题三个原则你的贡献就能顺畅地进入评审与合入流程。赞分享云原生运维测试可观测性【免费下载链接】chaos-meshA Chaos Engineering Platform for Kubernetes.项目地址https://gitcode.com/gh_mirrors/ch/chaos-mesh点击查看免费下载相关推荐Grounding DINO 开放集目标检测实战指南3 步跑通语言提示检测拆解 52.5 AP 背后的机制Grounding DINO 开放集目标检测实战指南3 步跑通语言提示检测拆解 52.5 AP 背后的机制 Grounding DINO 是 IDEA 研究人工智能计算机视觉预训练深度学习Buzz开发贡献流程从Fork到PR的完整步骤Buzz开发贡献流程从Fork到PR的完整步骤 引言为什么参与Buzz贡献 Buzz作为一款基于OpenAI Whisper的本地音频转录翻译工具依赖全人工智能语音音频本地部署桌面应用Formily 贡献指南从 Fork 到 PR 合并的完整开源参与流程Formily 贡献指南从 Fork 到 PR 合并的完整开源参与流程 本篇指南面向所有希望参与 Formily 开源项目的开发者完整梳理了从 Fork 仓前端UI组件上一篇如何为任何显卡解锁AI渲染终极跨平台DLSS-Enabler完全指南下一篇Privado企业级数据安全扫描工具如何重塑应用隐私合规体系创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考