merge master to 1.10, with fixes (#7682)
This commit is contained in:
Jennifer Rondeau
committed by
zacharysarah
zacharysarah
parent
7f40782850
commit
3d79703d23
@@ -60,6 +60,7 @@ changed by setting the <code>for_k8s_version</code> variable.
|
||||
{{ "{% include feature-state-deprecated.md " }}%}
|
||||
````
|
||||
|
||||
<<<<<<< HEAD
|
||||
## Glossary
|
||||
|
||||
You can reference glossary terms with an inclusion that will automatically update and replace content with the relevant links from [our glossary](/docs/reference/glossary/). When the term is moused-over by someone
|
||||
@@ -75,6 +76,24 @@ For example, the following include within the markdown will render to {% glossar
|
||||
{{ "{% glossary_tooltip text=" }}"cluster" term_id="cluster" %}
|
||||
````
|
||||
|
||||
||||||| merged common ancestors
|
||||
=======
|
||||
## Glossary
|
||||
|
||||
You can reference glossary terms with an inclusion that will automatically update and replace content with the relevant links from [our glossary](docs/reference/glossary/). When the term is moused-over by someone
|
||||
using the online documentation, the glossary entry will display a tooltip.
|
||||
|
||||
The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/master/_data/glossary](https://github.com/kubernetes/website/tree/master/_data/glossary), with a YAML file for each glossary term.
|
||||
|
||||
### Glossary Demo
|
||||
|
||||
For example, the following include within the markdown will render to {% glossary_tooltip text="cluster" term_id="cluster" %} with a tooltip:
|
||||
|
||||
````liquid
|
||||
{{ "{% glossary_tooltip text=" }}"cluster" term_id="cluster" %}
|
||||
````
|
||||
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
## Tabs
|
||||
|
||||
In a markdown page (`.md` file) on this site, you can add a tab set to display multiple flavors of a given solution.
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
<<<<<<< HEAD
|
||||
---
|
||||
title: Participating in SIG-DOCS
|
||||
---
|
||||
@@ -107,3 +108,115 @@ For more information about contributing to the Kubernetes documentation, see:
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
||||||| merged common ancestors
|
||||
=======
|
||||
---
|
||||
title: Participating in SIG-DOCS
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
SIG-DOCS is one of the [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) within the Kubernetes project, focused on writing, updating, and maintaining the documentation for Kubernetes as a whole.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture body %}
|
||||
|
||||
SIG Docs welcomes content and reviews from all contributors. Anyone can open a pull request (PR), and anyone is welcome to comment on content or pull requests in progress.
|
||||
|
||||
Within the Kubernetes project, you may also become a member, reviewer, or approver.
|
||||
These roles confer additional privileges and responsibilities when it comes to approving and committing changes.
|
||||
See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for more information on how membership works within the Kubernetes community.
|
||||
|
||||
## Roles and Responsibilities
|
||||
|
||||
The automation reads `/hold`, `/lgtm`, and `/approve` comments and sets labels on the pull request.
|
||||
When a pull request has the `lgtm` and `approve` labels without any `hold` labels, the pull request merges automatically.
|
||||
Kubernetes org members, and reviewers and approvers for SIG Docs can add comments to control the merge automation.
|
||||
|
||||
- Members
|
||||
|
||||
Any member of the [Kubernetes organization](https://github.com/kubernetes) can review a pull request, and SIG Docs team members frequently request reviews from members of other SIGs for technical accuracy.
|
||||
SIG Docs also welcomes reviews and feedback regardless of Kubernetes org membership.
|
||||
You can indicate your approval by adding a comment of `/lgtm` to a pull request.
|
||||
|
||||
- Reviewers
|
||||
|
||||
Reviewers are individuals who review documentation pull requests.
|
||||
|
||||
Automation assigns reviewers to pull requests, and contributors can request a review with a comment on the pull request: `/assign [@_github_handle]`.
|
||||
To indicate that a pull request requires no further changes, a reviewer should add comment to the pull request `/lgtm`.
|
||||
A reviewer indicates technical accuracy with a `lgtm` comment.
|
||||
|
||||
Reviewers can add a `/hold` comment to prevent the pull request from being merged.
|
||||
Another reviewer or approver can remove a hold with the comment: `/hold cancel`.
|
||||
|
||||
When a reviewer is assigned a pull request to review it is not a sole responsibility, and any other reviewer may also offer their opinions on the pull request.
|
||||
If a reviewer is requested, it is generally expected that the PR will be left to that reviewer to do their editorial pass on the content.
|
||||
If a PR author or SIG Docs maintainer requests a review, refrain from merging or closing the PR until the requested reviewer completes their review.
|
||||
|
||||
- Approvers
|
||||
|
||||
Approvers have the ability to merge a PR.
|
||||
|
||||
Approvers can indicate their approval with a comment to the pull request: `/approve`.
|
||||
An approver is indicating editorial approval with the an `/approve` comment.
|
||||
|
||||
Approvers can add a `/hold` comment to prevent the pull request from being merged.
|
||||
Another reviewer or approver can remove a hold with the comment: `/hold cancel`.
|
||||
|
||||
Approvers may skip further reviews for small pull requests if the proposed changes appear trivial and/or well-understood.
|
||||
An approver can indicate `/lgtm` or `/approve` in a PR comment to have a pull request merged, and all pull requests require at least one approver to provide their vote in order for the PR to be merged.
|
||||
|
||||
**Note:** There is a special case when an approver uses the comment: `/lgtm`. In these cases, the automation will add both `lgtm` and `approve` tags, skipping any further review.
|
||||
+{: .note }
|
||||
|
||||
For PRs that require no review (typos or otherwise trivial changes), approvers can enter an `lgtm` comment, indicating no need for further review and flagging the PR with approval to merge.
|
||||
|
||||
### Teams and groups within SIG Docs
|
||||
|
||||
You can get an overview of [SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs).
|
||||
The SIG Docs group defines two teams on Github:
|
||||
- [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
|
||||
- [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
|
||||
|
||||
These groups maintain the [Kubernetes website repository](https://github.com/kubernetes/website), which houses the content hosted at this site.
|
||||
Both can be referenced with their `@name` in github comments to communicate with everyone in that group.
|
||||
|
||||
These teams overlap, but do not exactly match, the groups used by the automation tooling.
|
||||
For assignment of issues, pull requests, and to support PR approvals, the automation uses information from the OWNERS file.
|
||||
|
||||
To volunteer as a reviewer or approver, make a pull request and add your Github handle to the relevant section in the [OWNERS file](https://github.com/kubernetes/community/blob/master/contributors/devel/owners.md).
|
||||
|
||||
**Note:** Reviewers and approvers must meet requirements for participation.
|
||||
For more information, see the [Kubernetes community](https://github.com/kubernetes/community/blob/master/community-membership.md#membership) repository.
|
||||
{: .note }
|
||||
|
||||
Documentation for the [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/devel/owners.md) explains how to maintain OWNERS for each repository that enables it.
|
||||
|
||||
The [Kubernetes website repository](https://github.com/kubernetes/website) has two automation (prow) [plugins enabled](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210):
|
||||
- blunderbuss
|
||||
- approve
|
||||
|
||||
These two plugins use the [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and [OWNERS_ALIAS](https://github.com/kubernetes/website/blob/master/OWNERS_ALIAS) files in our repo for configuration.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
For more information about contributing to the Kubernetes documentation, see:
|
||||
|
||||
* Review the SIG Docs [Style Guide](/docs/home/contribute/style-guide/).
|
||||
* Learn how to [stage your documentation changes](/docs/home/contribute/stage-documentation-changes/).
|
||||
* Learn about [writing a new topic](/docs/home/contribute/write-new-topic/).
|
||||
* Learn about [using page templates](/docs/home/contribute/page-templates/).
|
||||
* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/).
|
||||
* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/).
|
||||
* How to generate documentation:
|
||||
* Learn how to [generate Reference Documentation for Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
|
||||
* Learn how to [generate Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/)
|
||||
* Learn how to [generate Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/)
|
||||
* Learn how to [generate Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/)
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
@@ -142,6 +142,23 @@ The output is similar to this:
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
nginx 1/1 Running 0 13s 10.200.0.4 worker0
|
||||
|
||||
<<<<<<< HEAD
|
||||
### Versioning Kubernetes examples
|
||||
|
||||
Code examples and configuration examples that include version information should be consistent with the accompanying text. Identify the Kubernetes version in the **Before you begin** section.
|
||||
|
||||
To specify the Kubernetes version for a task or tutorial page:
|
||||
|
||||
- Include `min-kubernetes-server-version` in the front matter of the page.
|
||||
- In the **Before you begin** section, use `{{ "{% include tasks-tutorial-prereqs.md "}} %}`.
|
||||
|
||||
If the example YAML is in a standalone file, find and review the topics that include it as a reference.
|
||||
Verify that any topics using the standalone YAML have the appropriate version information defined.
|
||||
If a stand-alone YAML file is not referenced from any topics, consider deleting it instead of updating it.
|
||||
|
||||
For example, if you are writing a tutorial that is relevant to Kubernetes version 1.8, the front-matter of your markdown file should look something like:
|
||||
||||||| merged common ancestors
|
||||
=======
|
||||
### Versioning Kubernetes examples
|
||||
|
||||
Code examples and configuration examples that include version information should be consistent with the accompanying text. Identify the Kubernetes version in the **Before you begin** section.
|
||||
@@ -167,6 +184,24 @@ min-kubernetes-server-version: v1.8
|
||||
In code and configuration examples, do not include comments about alternative versions.
|
||||
Be careful to not include incorrect statements in your examples as comments, such as:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1 # earlier versions use...
|
||||
kind: Pod
|
||||
...
|
||||
```
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
<<<<<<< HEAD
|
||||
```yaml
|
||||
---
|
||||
title: <your tutorial title here>
|
||||
min-kubernetes-server-version: v1.8
|
||||
---
|
||||
```
|
||||
|
||||
In code and configuration examples, do not include comments about alternative versions.
|
||||
Be careful to not include incorrect statements in your examples as comments, such as:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1 # earlier versions use...
|
||||
kind: Pod
|
||||
@@ -174,12 +209,18 @@ kind: Pod
|
||||
```
|
||||
|
||||
## Kubernetes.io word list
|
||||
||||||| merged common ancestors
|
||||
{% comment %}## Kubernetes.io word list
|
||||
=======
|
||||
## Kubernetes.io word list
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
A list of Kubernetes-specific terms and words to be used consistently across the site.
|
||||
|
||||
<table>
|
||||
<<<<<<< HEAD
|
||||
<tr><th>Term</th><th>Usage</th></tr>
|
||||
<<<<<<< HEAD
|
||||
<tr><td>Kubernetes</td><td>Kubernetes should always be capitalized.</td></tr>
|
||||
<tr><td>Docker</td><td>Docker should always be capitalized.</td></tr>
|
||||
<tr><td>SIG Docs</td><td>SIG Docs rather than SIG-DOCS or other variations.</td></tr>
|
||||
@@ -193,6 +234,15 @@ A list of Kubernetes-specific terms and words to be used consistently across the
|
||||
<tr><td>TBD</td><td>TBD</td></tr>
|
||||
</table>{% endcomment %}
|
||||
>>>>>>> fix description about contribute style guide (#7592)
|
||||
||||||| merged common ancestors
|
||||
<tr><td>TBD</td><td>TBD</td></tr>
|
||||
</table>{% endcomment %}
|
||||
=======
|
||||
<tr><td>Kubernetes</td><td>Kubernetes should always be capitalized.</td></tr>
|
||||
<tr><td>Docker</td><td>Docker should always be capitalized.</td></tr>
|
||||
<tr><td>SIG Docs</td><td>SIG Docs rather than SIG-DOCS or other variations.</td></tr>
|
||||
</table>
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
## Callout Formatting
|
||||
Callouts help create different rhetorical appeal levels. Our documentation supports three different callouts: **Note:** {: .note}, **Caution:** {: .caution}, and **Warning:** {: .warning}.
|
||||
|
||||
Reference in New Issue
Block a user