这是本节可打印的多页视图点击这里开始打印.

开发 & 贡献指南

学习怎样开发 OpenFunction 及怎样贡献您的代码

1: 快速上手
2: 开发流程
3: Pull Request 流程

1 - 快速上手

本文将指导你如何在你的本地环境中开始构建 OpenFunction。

前提准备

如果你对开发控制器、管理器感兴趣，请参阅 sample-controller 和 kubebuilder。

Go

OpenFunction 基于 Kubernetes。它们都是用 Go 编写的。如果你没有 Go 开发环境，请先设置 Go 开发环境。

Kubernetes	要求的 Go 版本
1.18+	go>=1.12

提示：
确保你的 GOPATH 和 PATH 已经按照 Go 环境说明进行了配置。
在使用 MacOS 进行开发时，建议安装 macOS GNU tools。

Docker

OpenFunction 组件通常在 Kubernetes 中以容器方式部署。如果你需要在 Kubernetes 集群中部署 OpenFunction 组件，你需要提前安装 Docker。

依赖管理

OpenFunction 使用 Go Modules 管理依赖包。

制作镜像 & 运行

你可以通过修改 cmd/Dockerfile 来为你的本地环境制作 openfunction 镜像。

将镜像上传到你的个人镜像仓库后，在工作负载（Deployment）openfunction-controller-manager 中改变 openfunction 容器的镜像为你的个人镜像。

kubectl edit deployments.apps -n openfunction openfunction-controller-manager

保存后，Kubernetes 将自动应用新的镜像运行工作负载。

2 - 开发流程

本文件将向您介绍项目开发的详细过程。

步骤1. Fork

访问 https://github.com/OpenFunction/OpenFunction
点击 “Fork” 按钮，在你的 GitHub 账户中创建一个 fork 项目。

步骤2. 克隆 fork 项目至本地

Per Go’s workspace instructions, place OpenFunction code on your GOPATH using the following cloning procedure.

根据 Go 的 workspace instructions，使用以下克隆工序将 OpenFunction 代码放在你的 GOPATH 上。

定义一个本地目录：

export working_dir=$GOPATH/src/openfunction.io
export user={your github profile name}

将代码克隆到本地：

mkdir -p $working_dir
cd $working_dir
git clone https://github.com/$user/OpenFunction.git
cd $working_dir/OpenFunction
git remote add upstream https://github.com/OpenFunction/OpenFunction.git

# Never push to upstream master
git remote set-url --push upstream no_push

# Confirm your remotes make sense:
git remote -v

步骤3. 保持与上游分支的同步

git fetch upstream
git checkout main
git rebase upstream/main

步骤4. 增加新特性或补丁

从 master 中创建一个新分支：

git checkout -b myfeature

然后在 myfeature 分支上开发代码。参考 effective_go 有助于你的编码。

测试与构建

目前，make 规则只包含简单的检查，如 vet、unit 测试，很快会加入 e2e 测试。

使用 KubeBuilder

对于 Linux 操作系统，你可以下载并执行这个 KubeBuilder脚本。
对于 MacOS，你可以按照这个指南来安装 KubeBuilder。

运行与测试

make all
# Run every unit test
make test

运行 make help 以获得关于 make 的额外信息。

步骤5. 开新分支开发

与上游分支同步

测试完成后，让你本地的代码与上游分支保持同步有助于避免冲突。

# Rebase your master branch of your local repo.
git checkout main
git rebase upstream/main

# Then make your development branch in sync with master branch
git checkout new_feature
git rebase -i main

提交本地变化

git add <file>
git commit -s -m "add your description"

步骤6. 推送至你的 fork 仓库

当准备好审查时（或者只是为了建立一个异地的工作备份），把你的本地分支推送到 GitHub 上的 fork 仓库。

git push -f ${your_remote_name} myfeature

步骤7. 创建一个 PR

访问你在 GitHub 上的 fork 仓库 https://github.com/$user/OpenFunction
点击你的 myfeature 分支旁的 Compare & Pull Request 按钮
请查看 pull requests 流程，了解更多细节和建议

3 - Pull Request 流程

本文档将帮助你学习如何提交 pull requests。

本文档演示了向 OpenFunction 项目提交 PR 的过程和最佳实践。它可以为所有贡献者（尤其是新接触或不经常提交 PR 的开发者）提供有价值的参考。

在提交 PR 之前
- 运行本地验证
PR 的提交流程

在提交 PR 之前

本指南是为已经有 PR 要提交的贡献者准备的。如果你正在寻找关于如何搭建你的开发环境以及如何为 OpenFunction 贡献代码的信息，请参见开发指南。

确保你的 PR 符合我们的最佳实践。这包括遵循项目惯例，提交小型 PR，以及全面地进行评论。请阅读本文件末尾关于加快评审的最佳实践的更详细章节。

运行本地验证

你可以在提交 PR 之前运行这些本地验证，以预测持续集成的通过或失败。

PR 的提交流程

合并一个 PR 需要在自动合并 PR 之前完成以下步骤。关于每个步骤的细节，请参见下面的测试和合并工作流程部分。

生成 PR
Release notes – 包含以下一项：
- 在 release notes 中添加说明，或
- 上传 release notes 的标签
通过所有测试
从 reviewer 处获得一个 /lgtm 标签
从 owner 处获得一个 approval

如果你的 PR 符合上述所有步骤，它将进入提交队列被合并。当它成为下一个被合并的队列时，测试将运行第二次。如果所有的测试都通过了，PR 将被自动合并。

如有需要，编写 Release notes

任何带有用户可见变化的 PR 都需要 release notes，例如错误修复、功能添加和输出格式变化。

如果你不在 PR 模板中添加 release notes，那么在你创建 PR 后，“do-not-merge/release-note-label-needed” 的标签会自动添加到你的 PR 中。有几种方法可以更新它。

在 PR 描述中增加一个 release-note 部分。

对于有 release notes 的 PR：

```release-note
Your release note here
```

对于需要用户在切换到新版本时采取额外操作的 PR，请在发布说明中加入 “action required” 的字符串（不区分大小写）：

```release-note
action required: your release note here
```

对于不需要在发布时提及的 PR，只需写上 “NONE”（不区分大小写）：

```release-note
NONE
```

/release-note-none 注释命令仍然可以用来替代在 release-note 块中写 “NONE”，如果它留空的话。

要了解如何格式化您的 release notes，请查看 PR 模板以了解一个简单的例子。PR 的标题和正文注释可以在发布前的任何时候进行修改，以使其对发布注释友好。 // PR template TODO

Release notes 适用于主分支上的 PR 。对于 cherry-pick PR，请参阅 cherry-pick instructions 。这些规则的唯一例外是，当一个 PR 不是 cherry-pick，而是直接针对非主干分支时。在这种情况下，非主分支 PR 需要一个 release-note-* 标签。

// cherry-pick TODO

现在你的 release notes 已经成型了，让我们看看 PR 是如何被测试和合并的。

测试与合并工作流

OpenFunction 的合并工作流程使用注释来运行测试和标签来合并 PR。

注意：对于正在进行但尚未准备好接受审查的拉动请求，在 PR 标题前加上 “WIP” 或 “[WIP]”，并在 pull requests 描述中的检查清单中跟踪任何剩余的 TODO。

以下是 PR 从提交到合并的过程：

生成 pull request
@o8x-merge-robot 分配 reviewer //TODO

如果你不是的 OpenFunction 组织的成员：

Reviewer/OpenFunction 成员检查 PR 是否可以安全测试。如果是的话，他们会评论 /ok-to-test。
Reviewer 建议编辑
提交编辑至你的 PR 分支
重复最先的两个步骤
（可选）一些 reviewer 希望你在这一步合并（squash）提交的内容
Owner 被安排处理这次合并，并将在 PR 上添加 /approve 标签

如果你是一个项目的成员，或者一个评论了 /ok-to-test 的成员，该 PR 将被认为是可信的。然后提交前的测试就会运行：

自动测试运行。参见 PR 上的当前测试列表
如果测试失败，通过向你的 PR 分支推送编辑来解决问题
如果失败是偶然的，任何受信任的 PR 上的人都可以评论 /retest 来重新运行失败的测试

一旦测试通过，所有的失败都被评论为偶然的，或者评审员添加了 lgtm 和 approved 标签，PR 就进入了最后的合并队列。合并队列是必须的，以确保在你的 PR 上最后一次运行测试后，其他 PR 没有引入不兼容的变化。

该 PR 进入合并队列
合并队列触发了一个测试的重新运行，注释为 /test all [submit-queue 正在验证这个 PR 是否可以安全合并]。 2.1. 作者已经签署了 CLA（cncf-cla: yes 标签添加到 PR）。 2.2. 自上次应用 lgtm 标签以来，没有做出任何改变
如果测试失败，通过向你的 PR 分支推送编辑来解决问题
如果失败是偶然的，任何受信任的 PR 上的人都可以评论 /retest 来重新运行失败的测试
如果测试通过，合并队列将自动合并 PR

这就是最后一步了。你的 PR 现在被合并了。

标记未完成的 Pull Requests

如果你想在你的 pull requests 执行完成之前征求评论，你应该保留你的 pull requests，以确保合并队列不会试图合并它。有两种方法可以实现这一点。

你可以添加 /hold 或 /hold cancel 的注释命令
你可以在你的 pull requests 标题中添加或删除 WIP 或 [WIP] 前缀

当你使用评论命令时，GitHub 机器人会添加和删除 do-not-merge/hold 标签，当你编辑标题时，会添加和删除 do-not-merge/work in-progress 标签。当这两个标签存在时，你的 pull requests 将不被考虑合并。