开发者指南

该指南说明如何为开发Helm配置环境。

先决条件

  • Go最新版本
  • Kubernetes集群及kubectl（可选）
  • Git

构建 Helm

我们使用Make构建程序。最简单的开始方式是：

  1. $ make

注意： 如果不是从$GOPATH/src/helm.sh/helm路径执行就会失败。目录helm.sh不应该是软链接，否则 build 找不到相关的包。

有必要的话要先安装依赖，重新构建 vendor/ 目录，并验证配置。然后会编译 helm 并将其放到bin/helm。

在本地执行Helm，可以执行 bin/helm。

  • Helm运行在 macOS 和大多数发行版上，包括 Alpine。

执行测试

要运行所有测试（除了vendor/），执行 make test。作为先决条件，需要安装 golangci-lint。

贡献指南

我们欢迎你的贡献。 该项目已经设置了一些指南，为了保证 (a) 代码的高质量，(b) 保持项目一致， (c) 贡献遵循开源法律要求。我们的目的不是为贡献者增加负担，但是要构建优雅和高质量的开源代码， 这样我们的用户才能从中受益。

确保你已经阅读并理解主要贡献指南：

https://github.com/helm/helm/blob/main/CONTRIBUTING.md

代码结构

Helm项目的代码组织如下：

  • 独立的程序位于 cmd/。cmd/ 中的代码不是为库复用设计的。
  • 共享的库放在 pkg/。
  • scripts/ 目录包含很多实用程序脚本。大多数用于CI/CD流水线。

Go依赖管理在不断变化，而且在Helm生命周期中很可能发生变化。我们建议开发者 不要 手动管理依赖。 而是建议依靠项目的 Makefile 来处理。使用Helm 3时，建议使用Go 1.13及更新版本。

编写文档

从Helm 3开始，文档已经移动到了它自己的仓库中。当编制新特性时，请编写随附文档并提交到 helm-www 仓库。

有个例外： Helm CLI 输出 (英文) 是 helm 程序自己生成的。 查看 更新Helm CLI参考文档 来了解如何生成该输出。翻译后，不会生成CLI输出，但可以在 /content/<lang>/docs/helm 中找到。

Git 约定

我们使用Git作为版本控制系统。 main 分支是当前开发候选分支。发布版本会打tag。

我们通过GitHub的Pull Requests(PRs)接受更改。操作工作流如下：

  1. 进入 $GOPATH/src 目录，然后 mkdir helm.sh; cd helm.sh 并git clone这个 github.com/helm/helm仓库。
  2. Fork仓库到自己的GitHub账户
  3. 为 $GOPATH/src/helm.sh/helm 添加自己的远程仓库
  4. 创建一个新分支(git checkout -b feat/my-feature) 并在新分支上开发。
  5. 当你准备好待审查代码时，将分支推送到GitHub，并开一个新的pull request 给我们。

对于Git提交信息，我们遵循 语义化提交信息：

  1. fix(helm): add --foo flag to 'helm install'
  3. When 'helm install --foo bar' is run, this will print "foo" in the
  4. output regardless of the outcome of the installation.
  6. Closes #1234

常见提交类型：

  • fix: 修复bug或错误
  • feat: 添加新特性
  • docs: 更新文档
  • test: 完善测试
  • ref: 重构现有代码

通用范围：

  • helm: Helm CLI
  • pkg/lint: lint包。对任意包都遵循类似的约定
  • *: 两个或更多范围

了解更多：

  • 灵感来源于 Deis指南。
  • Karma Runner 定义 了语义提交信息的观点。

Go 约定

我们非常严格地遵守Go编码风格标准。典型方式是，执行 go fmt 可以让代码更加整洁。

我们通常也通过go lint 和gometalinter遵循推荐的约定。执行 make test-style 来测试风格一致性。

了解更多：

如果运行make test，不仅单元测试会执行，格式测试也会自执行。如果 make test失败，即使是因为格式方面的原因， 你的PR也不会被合并。

Next版本 Checklist →