whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh]sync contribution files for 1.22(Part-2)

Browse Source
This commit is contained in:
howieyuen
2021-08-20 15:26:01 +08:00
parent cdefcc3a8b
commit 742824d491
6 changed files with 84 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md
+34 -28
View File
@@ -159,12 +159,12 @@ will be different in your situation.
<!--
Here's an example of editing a comment in the Kubernetes source code.
In your local kubernetes/kubernetes repository, check out the master branch,
In your local kubernetes/kubernetes repository, check out the default branch,
and make sure it is up to date:
-->
以下在 Kubernetes 源代码中编辑注释的示例。
在您本地的 kubernetes/kubernetes 代码仓库中，检出 master 分支，并确保它是最新的：
在您本地的 kubernetes/kubernetes 代码仓库中，检出默认分支，并确保它是最新的：
```shell
cd <k8s-base>
@@ -173,9 +173,9 @@ git pull https://github.com/kubernetes/kubernetes master
```
<!--
Suppose this source file in the master branch has the typo "atmost":
Suppose this source file in that default branch has the typo "atmost":
-->
假设 master 分支中的下面源文件中包含拼写错误 "atmost"：
假设默认分支中的下面源文件中包含拼写错误 "atmost"：
[kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/apps/v1/types.go)
@@ -228,7 +228,6 @@ Go to `<k8s-base>` and run these scripts:
hack/update-generated-swagger-docs.sh
hack/update-openapi-spec.sh
hack/update-generated-protobuf.sh
hack/update-api-reference-docs.sh
```
<!-- Run `git status` to see what was generated. -->
@@ -238,8 +237,6 @@ hack/update-api-reference-docs.sh
On branch master
...
modified: api/openapi-spec/swagger.json
modified: api/swagger-spec/apps_v1.json
modified: docs/api-reference/apps/v1/definitions.html
modified: staging/src/k8s.io/api/apps/v1/generated.proto
modified: staging/src/k8s.io/api/apps/v1/types.go
modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go
@@ -310,24 +307,27 @@ In the preceding section, you edited a file in the master branch and then ran sc
to generate an OpenAPI spec and related files. Then you submitted your changes in a pull request
to the master branch of the kubernetes/kubernetes repository. Now suppose you want to backport
your change into a release branch. For example, suppose the master branch is being used to develop
Kubernetes version 1.10, and you want to backport your change into the release-1.9 branch.
Kubernetes version {{< skew latestVersion >}}, and you want to backport your change into the
release-{{< skew prevMinorVersion >}} branch.
-->
### 将你的提交 Cherrypick 到发布分支
在上一节中，你在 master 分支中编辑了一个文件，然后运行了脚本用来生成 OpenAPI 规范和相关文件。
然后用 PR 将你的更改提交到 kubernetes/kubernetes 代码仓库的 master 分支中。
现在，需要将你的更改反向移植到已经发布的分支。
例如，假设 master 分支被用来开发 Kubernetes 1.10 版，并且你想将更改反向移植到 release-1.9 分支。
例如，假设 master 分支被用来开发 Kubernetes {{< skew latestVersion >}} 版，
并且你想将更改反向移植到 release-{{< skew prevMinorVersion >}} 分支。
<!--
Recall that your pull request has two commits: one for editing `types.go`
and one for the files generated by scripts. The next step is to propose a cherry pick of your first
commit into the release-1.9 branch. The idea is to cherry pick the commit that edited `types.go`, but not
the commit that has the results of running the scripts. For instructions, see
commit into the release-{{< skew prevMinorVersion >}} branch. The idea is to cherry pick the commit
that edited `types.go`, but not the commit that has the results of running the scripts. For instructions, see
[Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md).
-->
回想一下，您的 PR 有两个提交：一个用于编辑 `types.go`，一个用于由脚本生成的文件。
下一步是将你的第一次提交 cherrypick 到 release-1.9 分支。这样做的原因是仅 cherrypick 编辑了 types.go 的提交，
下一步是将你的第一次提交 cherrypick 到 release-{{< skew prevMinorVersion >}} 分支。
这样做的原因是仅 cherrypick 编辑了 types.go 的提交，
而不是具有脚本运行结果的提交。
有关说明，请参见[提出 Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。
@@ -337,16 +337,17 @@ pull request. If you don't have those permissions, you will need to work with so
and milestone for you.
-->
{{< note >}}
提出 Cherry Pick 要求你有权在 PR 中设置标签和里程碑。如果您没有这些权限，
提出 Cherry Pick 要求你有权在 PR 中设置标签和里程碑。如果你没有这些权限，
则需要与可以为你设置标签和里程碑的人员合作。
{{< /note >}}
<!--
When you have a pull request in place for cherry picking your one commit into the release-1.9 branch,
the next step is to run these scripts in the release-1.9 branch of your local environment.
When you have a pull request in place for cherry picking your one commit into the
release-{{< skew prevMinorVersion >}} branch, the next step is to run these scripts in the
release-{{< skew prevMinorVersion >}} branch of your local environment.
-->
当你发起 PR 将你的一个提交 cherry pick 到 release-1.9 分支中时，下一步是在本地环境的 release-1.9
分支中运行如下脚本。
当你发起 PR 将你的一个提交 cherry pick 到 release-{{< skew prevMinorVersion >}} 分支中时，
下一步是在本地环境的 release-{{< skew prevMinorVersion >}} 分支中运行如下脚本。
```shell
hack/update-generated-swagger-docs.sh
@@ -357,24 +358,29 @@ hack/update-api-reference-docs.sh
<!--
Now add a commit to your cherry-pick pull request that has the recently generated OpenAPI spec
and related files. Monitor your pull request until it gets merged into the release-1.9 branch.
and related files. Monitor your pull request until it gets merged into the
release-{{< skew prevMinorVersion >}} branch.
-->
现在将提交添加到您的 Cherry-Pick PR 中，该 PR 中包含最新生成的 OpenAPI 规范和相关文件。
关注你的 PR，直到其合并到 release-1.9 分支中为止。
关注你的 PR，直到其合并到 release-{{< skew prevMinorVersion >}} 分支中为止。
<!--
At this point, both the master branch and the release-1.9 branch have your updated `types.go`
At this point, both the master branch and the release-{{< skew prevMinorVersion >}} branch have your updated `types.go`
file and a set of generated files that reflect the change you made to `types.go`. Note that the
generated OpenAPI spec and other generated files in the release-1.9 branch are not necessarily
the same as the generated files in the master branch. The generated files in the release-1.9 branch
contain API elements only from Kubernetes 1.9. The generated files in the master branch might contain
API elements that are not in 1.9, but are under development for 1.10.
generated OpenAPI spec and other generated files in the release-{{< skew prevMinorVersion >}} branch are not necessarily
the same as the generated files in the master branch. The generated files in the release-{{< skew prevMinorVersion >}} branch
contain API elements only from Kubernetes {{< skew prevMinorVersion >}}. The generated files in the master branch might contain
API elements that are not in {{< skew prevMinorVersion >}}, but are under development for {{< skew latestVersion >}}.
-->
此时，master 分支和 release-1.9 分支都具有更新的 `types.go` 文件和一组生成的文件，
此时，master 分支和 release-{{< skew prevMinorVersion >}}
分支都具有更新的 `types.go` 文件和一组生成的文件，
这些文件反映了对 `types.go` 所做的更改。
请注意，生成的 OpenAPI 规范和其他 release-1.9 分支中生成的文件不一定与 master 分支中生成的文件相同。
release-1.9 分支中生成的文件仅包含来自 Kubernetes 1.9 的 API 元素。
master 分支中生成的文件可能包含不在 1.9 中但正在为 1.10 开发的 API 元素。
请注意，生成的 OpenAPI 规范和其他 release-{{< skew prevMinorVersion >}}
分支中生成的文件不一定与 master 分支中生成的文件相同。
release-{{< skew prevMinorVersion >}} 分支中生成的文件仅包含来自
Kubernetes {{< skew prevMinorVersion >}} 的 API 元素。
master 分支中生成的文件可能包含不在 {{< skew prevMinorVersion >}}
中但正在为 {{< skew latestVersion >}} 开发的 API 元素。
<!--
## Generating the published reference docs