Normalize case: Github -> GitHub (#13828)
This commit is contained in:
Danny Berger
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
5ffd272aef
commit
4029a7ab5e
@@ -140,7 +140,7 @@ Release Notes:
|
||||
* Update Exec and Portforward client to use pod subresource [#7715][127] (csrwng)
|
||||
* Added NFS to PV structs [#7564][128] (markturansky)
|
||||
* Fix environment variable error in Vagrant docs [#7904][129] (posita)
|
||||
* Adds a simple release-note builder that scrapes the Github API for recent PRs [#7616][130](brendandburns)
|
||||
* Adds a simple release-note builder that scrapes the GitHub API for recent PRs [#7616][130](brendandburns)
|
||||
* Scheduler ignores nodes that are in a bad state [#7668][131] (bprashanth)
|
||||
* Set GOMAXPROCS for etcd [#7863][132] (fgrzadkowski)
|
||||
* Auto-generated conversion methods calling one another [#7556][133] (wojtek-t)
|
||||
@@ -444,7 +444,7 @@ Simple theme. Powered by [Blogger][385].
|
||||
[127]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7715 "Update Exec and Portforward client to use pod subresource"
|
||||
[128]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7564 "Added NFS to PV structs"
|
||||
[129]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7904 "Fix environment variable error in Vagrant docs"
|
||||
[130]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7616 "Adds a simple release-note builder that scrapes the Github API for recent PRs"
|
||||
[130]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7616 "Adds a simple release-note builder that scrapes the GitHub API for recent PRs"
|
||||
[131]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7668 "Scheduler ignores nodes that are in a bad state"
|
||||
[132]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7863 "Set GOMAXPROCS for etcd"
|
||||
[133]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7556 "Auto-generated conversion methods calling one another"
|
||||
|
||||
@@ -169,7 +169,7 @@ The LPC demo was done with a simple container that did not require network conne
|
||||
In May 2015, the criu branch of libcontainer was merged into master. Using the newly-introduced lightweight [runC](https://blog.docker.com/2015/06/runc/) container runtime, container migration was demo’ed at DockerCon15. In this
|
||||
[](https://www.youtube.com/watch?v=?mL9AFkJJAq0) (minute 23:00), a container running Quake was checkpointed and restored on a different machine, effectively implementing container migration.
|
||||
|
||||
At the time of this writing, there are two repos on Github that have native C/R support in Docker:
|
||||
At the time of this writing, there are two repos on GitHub that have native C/R support in Docker:
|
||||
- [Docker 1.5](https://github.com/SaiedKazemi/docker/tree/cr) (old libcontainer, relatively stable)
|
||||
- [Docker 1.7](https://github.com/boucher/docker/tree/cr-combined) (newer, less stable)
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Now you got your Raspberry Pi Cluster all setup, it is time to run some software
|
||||
First step is to make sure every Pi has Hypriot running, if not yet please check the [getting started guide](http://blog.hypriot.com/getting-started-with-docker-on-your-arm-device/) of them. Also hook up the cluster switch to a network so that Internet is available and every Pi get an IP-address assigned via DHCP. Because we will be running multiple Pi’s it is practical to give each Pi a unique hostname. I renamed my Pi’s to rpi-master, rpi-node-1, rpi-node-2, etc for my convenience. Note that on Hypriot the hostname is set by editing the /boot/occidentalis.txt file, not the /etc/hostname. You could also set the hostname using the Hypriot flash tool.
|
||||
|
||||
|
||||
The most important thing about running software on a Pi is the availability of an ARM distribution. Thanks to [Brendan Burns](https://twitter.com/brendandburns), there are Kubernetes components for ARM available in the [Google Cloud Registry](https://cloud.google.com/container-registry/docs/). That’s great. The second hurdle is how to install Kubernetes. There are two ways; directly on the system or in a Docker container. Although the container support has an experimental status, I choose to go for that because it makes it easier to install Kubernetes for you. Kubernetes requires several processes (etcd, flannel, kubectl, etc) to run on a node, which should be started in a specific order. To ease that, systemd services are made available to start the necessary processes in the right way. Also the systemd services make sure that Kubernetes is spun up when a node is (re)booted. To make the installation real easy I created an simple install script for the master node and the worker nodes. All is available at [Github](https://github.com/awassink/k8s-on-rpi). So let’s get started now!
|
||||
The most important thing about running software on a Pi is the availability of an ARM distribution. Thanks to [Brendan Burns](https://twitter.com/brendandburns), there are Kubernetes components for ARM available in the [Google Cloud Registry](https://cloud.google.com/container-registry/docs/). That’s great. The second hurdle is how to install Kubernetes. There are two ways; directly on the system or in a Docker container. Although the container support has an experimental status, I choose to go for that because it makes it easier to install Kubernetes for you. Kubernetes requires several processes (etcd, flannel, kubectl, etc) to run on a node, which should be started in a specific order. To ease that, systemd services are made available to start the necessary processes in the right way. Also the systemd services make sure that Kubernetes is spun up when a node is (re)booted. To make the installation real easy I created an simple install script for the master node and the worker nodes. All is available at [GitHub](https://github.com/awassink/k8s-on-rpi). So let’s get started now!
|
||||
|
||||
### Installing the Kubernetes master node
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ Note taker: Rob Hirschfeld
|
||||
* *SIG Report:*
|
||||
* Release Automation and an introduction to David McMahon
|
||||
* Docs and k8s website redesign proposal and an introduction to John Mulhausen
|
||||
* This will allow the system to build docs correctly from Github w/ minimal effort
|
||||
* This will allow the system to build docs correctly from GitHub w/ minimal effort
|
||||
* Will be check-in triggered
|
||||
* Getting website style updates
|
||||
* Want to keep authoring really light
|
||||
@@ -33,7 +33,7 @@ Note taker: Rob Hirschfeld
|
||||
* discussion about release criteria: we will hold release date for bugs
|
||||
* Testing flake surge is over (one time event and then maintain test stability)
|
||||
* 1.3 Planning (time +40 minutes)
|
||||
* working to cleanup the Github milestones — they should be a source of truth. you can use Github for bug reporting
|
||||
* working to cleanup the GitHub milestones — they should be a source of truth. you can use GitHub for bug reporting
|
||||
* push off discussion while 1.2 crunch is under
|
||||
* Framework
|
||||
* dates
|
||||
|
||||
@@ -14,7 +14,7 @@ _--Justin_
|
||||
|
||||
You started with an excellent foundation - good declarative functionality, built around a solid API with a well defined schema and the machinery so that we could evolve going forwards. And sure enough, over your first year you grew so fast: autoscaling, HTTP load-balancing support (Ingress), support for persistent workloads including clustered databases (PetSets). You’ve made friends with more clouds (welcome Azure & OpenStack to the family), and even started to span zones and clusters (Federation). And these are just some of the most visible changes - there’s so much happening inside that brain of yours!
|
||||
|
||||
I think it’s wonderful you’ve remained so open in all that you do - you seem to write down everything on Github - for better or worse. I think we’ve all learned a lot about that on the way, like the perils of having engineers make scaling statements that are then weighed against claims made without quite the same framework of precision and rigor. But I’m proud that you chose not to lower your standards, but rose to the challenge and just ran faster instead - it might not be the most realistic approach, but it is the only way to move mountains!
|
||||
I think it’s wonderful you’ve remained so open in all that you do - you seem to write down everything on GitHub - for better or worse. I think we’ve all learned a lot about that on the way, like the perils of having engineers make scaling statements that are then weighed against claims made without quite the same framework of precision and rigor. But I’m proud that you chose not to lower your standards, but rose to the challenge and just ran faster instead - it might not be the most realistic approach, but it is the only way to move mountains!
|
||||
|
||||
And yet, somehow, you’ve managed to avoid a lot of the common dead-ends that other open source software has fallen into, particularly as those projects got bigger and the developers end up working on it more than they use it directly. How did you do that? There’s a probably-apocryphal story of an employee at IBM that makes a huge mistake, and is summoned to meet with the big boss, expecting to be fired, only to be told “We just spent several million dollars training you. Why would we want to fire you?”. Despite all the investment google is pouring into you (along with Redhat and others), I sometimes wonder if the mistakes we are avoiding could be worth even more. There is a very open development process, yet there’s also an “oracle” that will sometimes course-correct by telling us what happens two years down the road if we make a particular design decision. This is a parent you should probably listen to!
|
||||
|
||||
|
||||
@@ -52,7 +52,7 @@ We’re done with step 1. In my experience it usually takes less than 5 minutes
|
||||
|
||||
|
||||
## Deploy an Application to Kubernetes
|
||||
First go to [Codefresh and create an account using Github, Bitbucket, or Gitlab](https://codefresh.io/kubernetes-deploy/). As mentioned previously, Codefresh is free for both open source and smaller private projects. We’ll use it to create the configuration Yaml necessary to deploy our application to Kubernetes. Then we'll deploy our application and automate the process to happen every time we commit code changes. Here are the steps:
|
||||
First go to [Codefresh and create an account using GitHub, Bitbucket, or Gitlab](https://codefresh.io/kubernetes-deploy/). As mentioned previously, Codefresh is free for both open source and smaller private projects. We’ll use it to create the configuration Yaml necessary to deploy our application to Kubernetes. Then we'll deploy our application and automate the process to happen every time we commit code changes. Here are the steps:
|
||||
|
||||
1. 1.Create a Codefresh account
|
||||
2. 2.Connect to Google Cloud (or other cluster)
|
||||
|
||||
@@ -5,7 +5,7 @@ slug: introducing-kubeflow-composable
|
||||
url: /blog/2017/12/Introducing-Kubeflow-Composable
|
||||
---
|
||||
|
||||
**_Today’s post is by David Aronchick and Jeremy Lewi, a PM and Engineer on the Kubeflow project, a new open source Github repo dedicated to making using machine learning (ML) stacks on Kubernetes easy, fast and extensible._**
|
||||
**_Today’s post is by David Aronchick and Jeremy Lewi, a PM and Engineer on the Kubeflow project, a new open source GitHub repo dedicated to making using machine learning (ML) stacks on Kubernetes easy, fast and extensible._**
|
||||
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ Worse, these deployments are so tied to the clusters they have been deployed to
|
||||
|
||||
|
||||
## Introducing Kubeflow
|
||||
To address these concerns, we’re announcing the creation of the Kubeflow project, a new open source Github repo dedicated to making using ML stacks on Kubernetes easy, fast and extensible. This repository contains:
|
||||
To address these concerns, we’re announcing the creation of the Kubeflow project, a new open source GitHub repo dedicated to making using ML stacks on Kubernetes easy, fast and extensible. This repository contains:
|
||||
|
||||
- JupyterHub to create & manage interactive Jupyter notebooks
|
||||
- A Tensorflow [Custom Resource](/docs/concepts/api-extension/custom-resources/) (CRD) that can be configured to use CPUs or GPUs, and adjusted to the size of a cluster with a single setting
|
||||
|
||||
@@ -86,14 +86,14 @@ It’d be impossible to have gotten where we are without enormous help from ever
|
||||
* [PyTorch operator](https://github.com/kubeflow/pytorch-operator) for running PyTorch jobs
|
||||
* [Seldon Core](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/seldon) for running complex model deployments and non-TensorFlow serving
|
||||
|
||||
It’s difficult to overstate how much the community has helped bring all these projects (and more) to fruition. Just a few of the contributing companies include: Alibaba Cloud, Ant Financial, Caicloud, Canonical, Cisco, Datawire, Dell, Github, Google, Heptio, Huawei, Intel, Microsoft, Momenta, One Convergence, Pachyderm, Project Jupyter, Red Hat, Seldon, Uber and Weaveworks.
|
||||
It’s difficult to overstate how much the community has helped bring all these projects (and more) to fruition. Just a few of the contributing companies include: Alibaba Cloud, Ant Financial, Caicloud, Canonical, Cisco, Datawire, Dell, GitHub, Google, Heptio, Huawei, Intel, Microsoft, Momenta, One Convergence, Pachyderm, Project Jupyter, Red Hat, Seldon, Uber and Weaveworks.
|
||||
|
||||
# Learning More
|
||||
|
||||
If you’d like to try out Kubeflow, we have a number of options for you:
|
||||
|
||||
1. You can use sample walkthroughs hosted on [Katacoda](https://www.katacoda.com/kubeflow)
|
||||
2. You can follow a guided tutorial with existing models from the [examples repository](https://github.com/kubeflow/examples). These include the [Github Issue Summarization](https://github.com/kubeflow/examples/tree/master/github_issue_summarization), [MNIST](https://github.com/kubeflow/examples/tree/master/mnist) and [Reinforcement Learning with Agents](https://github.com/kubeflow/examples/tree/master/agents).
|
||||
2. You can follow a guided tutorial with existing models from the [examples repository](https://github.com/kubeflow/examples). These include the [GitHub Issue Summarization](https://github.com/kubeflow/examples/tree/master/github_issue_summarization), [MNIST](https://github.com/kubeflow/examples/tree/master/mnist) and [Reinforcement Learning with Agents](https://github.com/kubeflow/examples/tree/master/agents).
|
||||
3. You can start a cluster on your own and try your own model. Any Kubernetes conformant cluster will support Kubeflow including those from contributors [Caicloud](https://www.prnewswire.com/news-releases/caicloud-releases-its-kubernetes-based-cluster-as-a-service-product-claas-20-and-the-first-tensorflow-as-a-service-taas-11-while-closing-6m-series-a-funding-300418071.html), [Canonical](https://jujucharms.com/canonical-kubernetes/), [Google](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-container-cluster), [Heptio](https://heptio.com/products/kubernetes-subscription/), [Mesosphere](https://github.com/mesosphere/dcos-kubernetes-quickstart), [Microsoft](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough), [IBM](https://cloud.ibm.com/docs/containers?topic=containers-cs_cluster_tutorial#cs_cluster_tutorial), [Red Hat/Openshift ](https://docs.openshift.com/container-platform/3.3/install_config/install/quick_install.html#install-config-install-quick-install)and [Weaveworks](https://www.weave.works/product/cloud/).
|
||||
|
||||
There were also a number of sessions at KubeCon + CloudNativeCon EU 2018 covering Kubeflow. The links to the talks are here; the associated videos will be posted in the coming days.
|
||||
|
||||
@@ -167,10 +167,10 @@ You can find out more on the [CoreDNS Blog](https://coredns.io/blog).
|
||||
|
||||
CoreDNS is an incubated [CNCF](https:://cncf.io) project.
|
||||
|
||||
We're most active on Slack (and Github):
|
||||
We're most active on Slack (and GitHub):
|
||||
|
||||
- Slack: #coredns on <https://slack.cncf.io>
|
||||
- Github: <https://github.com/coredns/coredns>
|
||||
- GitHub: <https://github.com/coredns/coredns>
|
||||
|
||||
More resources can be found:
|
||||
|
||||
|
||||
@@ -76,7 +76,7 @@ Don't forget: keeping these logs inside the cluster is a security threat in
|
||||
|
||||
**Centralising authentication and authorisation across an organisation (aka Single Sign On) helps onboarding, offboarding, and consistent permissions for users**.
|
||||
|
||||
Integrating Kubernetes with third party auth providers (like Google or Github) uses the remote platform's identity guarantees (backed up by things like 2FA) and prevents administrators having to reconfigure the Kubernetes API server to add or remove users.
|
||||
Integrating Kubernetes with third party auth providers (like Google or GitHub) uses the remote platform's identity guarantees (backed up by things like 2FA) and prevents administrators having to reconfigure the Kubernetes API server to add or remove users.
|
||||
|
||||
[Dex](https://github.com/coreos/dex) is an OpenID Connect Identity (OIDC) and OAuth 2.0 provider with pluggable connectors. Pusher takes this a stage further with [some custom tooling](https://thenewstack.io/kubernetes-single-sign-one-less-identity/), and there are some [other](https://github.com/negz/kuberos) [helpers](https://github.com/micahhausler/k8s-oidc-helper) available with slightly different use cases.
|
||||
|
||||
|
||||
@@ -47,5 +47,5 @@ Kubebuilder is a project under [SIG API Machinery][SIG-APIMachinery] and is bein
|
||||
|
||||
- Kubebuilder [chat room on Slack][slack-channel]
|
||||
- SIG [mailing list][mailing-list]
|
||||
- [Github issues][open-an-issue]
|
||||
- [GitHub issues][open-an-issue]
|
||||
- Send a pull request in the [kubebuilder repo][kubebuilder-repo]
|
||||
|
||||
@@ -28,7 +28,7 @@ Some of the ways that you can contribute to the Kubernetes community without wri
|
||||
- Project, program, and [product management](https://github.com/kubernetes/community/blob/master/sig-pm/README.md)
|
||||
- And many more!
|
||||
|
||||
The guide to get started with Kubernetes project contribution is [documented on Github](https://github.com/kubernetes/community/tree/master/contributors/guide), and as the Non-Code Contributors Guide is a part of that Kubernetes Contributors Guide, it can be found [here](https://github.com/kubernetes/community/blob/master/contributors/guide/non-code-contributions.md). As stated earlier, this list is not exhaustive and will continue to be a work in progress.
|
||||
The guide to get started with Kubernetes project contribution is [documented on GitHub](https://github.com/kubernetes/community/tree/master/contributors/guide), and as the Non-Code Contributors Guide is a part of that Kubernetes Contributors Guide, it can be found [here](https://github.com/kubernetes/community/blob/master/contributors/guide/non-code-contributions.md). As stated earlier, this list is not exhaustive and will continue to be a work in progress.
|
||||
|
||||
To date, the typical Non-Code contributions fall into the following categories:
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ cid: community
|
||||
<p>Get the latest news and updates.</p>
|
||||
</div>
|
||||
<div>
|
||||
<a href="https://github.com/kubernetes/kubernetes">Github Project</a>
|
||||
<a href="https://github.com/kubernetes/kubernetes">GitHub Project</a>
|
||||
<p>Check out the project and consider contributing.</p>
|
||||
</div>
|
||||
<div>
|
||||
|
||||
@@ -26,7 +26,7 @@ For information on the Kubernetes documentation style guide, see the [style guid
|
||||
for specific criteria for membership.
|
||||
- A SIG Docs _reviewer_ is a member of the Kubernetes organization who has
|
||||
expressed interest in reviewing documentation pull requests and who has been
|
||||
added to the appropriate Github group and `OWNERS` files in the Github
|
||||
added to the appropriate GitHub group and `OWNERS` files in the GitHub
|
||||
repository, by a SIG Docs Approver.
|
||||
- A SIG Docs _approver_ is a member in good standing who has shown a continued
|
||||
commitment to the project. An approver can merge pull requests
|
||||
|
||||
@@ -38,7 +38,7 @@ for weekly rotations. The PR wrangler's duties include:
|
||||
[Intermediate contributing](/docs/contribute/intermediate/) for guidelines
|
||||
about how SIG Docs uses metadata.
|
||||
|
||||
### Helpful Github queries for wranglers
|
||||
### Helpful GitHub queries for wranglers
|
||||
|
||||
The following queries are helpful when wrangling. After working through these three queries, the remaining list of PRs to be
|
||||
reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one).
|
||||
|
||||
@@ -67,7 +67,7 @@ and the [code of conduct](/community/code-of-conduct/)
|
||||
|
||||
### Find a PR to review
|
||||
|
||||
To see all open PRs, go to the **Pull Requests** tab in the Github repository.
|
||||
To see all open PRs, go to the **Pull Requests** tab in the GitHub repository.
|
||||
A PR is eligible for review when it meets all of the following criteria:
|
||||
|
||||
- Has the `cncf-cla:yes` tag
|
||||
@@ -166,7 +166,7 @@ has signed the CLA.
|
||||
- If the PR does not need additional technical review, add the
|
||||
text `/lgtm` as well.
|
||||
- If the PR *does* need additional technical review, add the text
|
||||
`/assign` with the Github username of the person who needs to
|
||||
`/assign` with the GitHub username of the person who needs to
|
||||
provide technical review. Look at the `reviewers` field in the
|
||||
front-matter at the top of a given Markdown file to see who can
|
||||
provide technical review.
|
||||
@@ -212,7 +212,7 @@ true:
|
||||
|
||||
#### If the file is already changed by the PR
|
||||
|
||||
This method uses the Github UI. If you prefer, you can use the command line
|
||||
This method uses the GitHub UI. If you prefer, you can use the command line
|
||||
even if the file you want to change is part of the PR, if you are more
|
||||
comfortable working that way.
|
||||
|
||||
@@ -227,7 +227,7 @@ author's fork) and now shows up in the PR and your changes are reflected in
|
||||
the **Files changed** tab. Leave a comment letting the PR author know you
|
||||
changed the PR.
|
||||
|
||||
If the author is using the command line rather than the Github UI to work on
|
||||
If the author is using the command line rather than the GitHub UI to work on
|
||||
this PR, they need to fetch their fork's changes and rebase their local branch
|
||||
on the branch in their fork, before doing additional work on the PR.
|
||||
|
||||
@@ -235,7 +235,7 @@ on the branch in their fork, before doing additional work on the PR.
|
||||
|
||||
If changes need to be made to a file that is not yet included in the PR, you
|
||||
need to use the command line. You can always use this method, if you prefer it
|
||||
to the Github UI.
|
||||
to the GitHub UI.
|
||||
|
||||
1. Get the URL for the author's fork. You can find it near the bottom of the
|
||||
**Conversation** tab. Look for the text **Add more commits by pushing to**.
|
||||
@@ -244,7 +244,7 @@ to the Github UI.
|
||||
|
||||
2. Add the fork as a remote. In your terminal, go to your clone of the
|
||||
repository. Decide on a name to give the remote (such as the author's
|
||||
Github username), and add the remote using the following syntax:
|
||||
GitHub username), and add the remote using the following syntax:
|
||||
|
||||
```bash
|
||||
git remote add <name> <url-of-fork>
|
||||
@@ -273,10 +273,10 @@ to the Github UI.
|
||||
git push <remote-name> <branch-name>
|
||||
```
|
||||
|
||||
7. Go back to the Github IU and refresh the PR. Your changes appear. Leave the
|
||||
7. Go back to the GitHub IU and refresh the PR. Your changes appear. Leave the
|
||||
PR author a comment letting them know you changed the PR.
|
||||
|
||||
If the author is using the command line rather than the Github UI to work on
|
||||
If the author is using the command line rather than the GitHub UI to work on
|
||||
this PR, they need to fetch their fork's changes and rebase their local branch
|
||||
on the branch in their fork, before doing additional work on the PR.
|
||||
|
||||
@@ -284,7 +284,7 @@ on the branch in their fork, before doing additional work on the PR.
|
||||
|
||||
For changes that require multiple files or changes that involve creating new
|
||||
files or moving files around, working from a local Git clone makes more sense
|
||||
than relying on the Github UI. These instructions use the `git` command and
|
||||
than relying on the GitHub UI. These instructions use the `git` command and
|
||||
assume that you have it installed locally. You can adapt them to use a local
|
||||
graphical Git client instead.
|
||||
|
||||
@@ -301,7 +301,7 @@ on the Kubernetes documentation.
|
||||
```
|
||||
|
||||
The new directory `website` is created in your current directory, with
|
||||
the contents of the Github repository.
|
||||
the contents of the GitHub repository.
|
||||
|
||||
2. Change to the new `website` directory. Rename the default `origin` remote
|
||||
to `upstream`.
|
||||
@@ -312,7 +312,7 @@ on the Kubernetes documentation.
|
||||
git remote rename origin upstream
|
||||
```
|
||||
|
||||
3. If you have not done so, create a fork of the repository on Github. In your
|
||||
3. If you have not done so, create a fork of the repository on GitHub. In your
|
||||
web browser, go to
|
||||
[https://github.com/kubernetes/website](https://github.com/kubernetes/website)
|
||||
and click the **Fork** button. After a few seconds, you are redirected to
|
||||
@@ -389,10 +389,10 @@ most up-to-date version of that branch.
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Do not reference a Github issue or pull request by ID or URL in the
|
||||
Do not reference a GitHub issue or pull request by ID or URL in the
|
||||
commit message. If you do, it will cause that issue or pull request to get
|
||||
a notification every time the commit shows up in a new Git branch. You can
|
||||
link issues and pull requests together later, in the Github UI.
|
||||
link issues and pull requests together later, in the GitHub UI.
|
||||
{{< /note >}}
|
||||
|
||||
5. Optionally, you can test your change by staging the site locally using the
|
||||
@@ -413,13 +413,13 @@ most up-to-date version of that branch.
|
||||
The results are more repeatable if you include the branch name.
|
||||
|
||||
7. At this point, if you go to https://github.com/kubernetes/website in your
|
||||
web browser, Github detects that you pushed a new branch to your fork and
|
||||
web browser, GitHub detects that you pushed a new branch to your fork and
|
||||
offers to create a pull request. Fill in the pull request template.
|
||||
|
||||
- The title should be no more than 50 characters and summarize the intent
|
||||
of the change.
|
||||
- The long-form description should contain more information about the fix,
|
||||
including a line like `Fixes #12345` if the pull request fixes a Github
|
||||
including a line like `Fixes #12345` if the pull request fixes a GitHub
|
||||
issue. This will cause the issue to be closed automatically when the
|
||||
pull request is merged.
|
||||
- You can add labels or other metadata and assign reviewers. See
|
||||
@@ -458,7 +458,7 @@ most up-to-date version of that branch.
|
||||
11. If someone else's change is merged into the branch your work is based on,
|
||||
and you have made changes to the same parts of the same files, a conflict
|
||||
might occur. If the pull request shows that there are conflicts to resolve,
|
||||
you can resolve them using the Github UI or you can resolve them locally.
|
||||
you can resolve them using the GitHub UI or you can resolve them locally.
|
||||
|
||||
First, do step 10 to be sure that your fork and your local branch are in
|
||||
the same state.
|
||||
@@ -578,7 +578,7 @@ These guidelines are not set in stone and are subject to change.
|
||||
- Priority labels: define the relative severity of the issue. These do not
|
||||
conform to those outlined in the
|
||||
[Kubernetes contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority), and can be one of `P1`, `P2`, or `P3`, if set.
|
||||
- To add a label, you can use Github's **Labels** widget if you are a Sig Docs
|
||||
- To add a label, you can use GitHub's **Labels** widget if you are a Sig Docs
|
||||
approver. Anyone who is a member of the Kubernetes organization can add a
|
||||
label by leaving a comment like `/label <label-to-add>`. The label must
|
||||
already exist. If you try to add a label that does not exist, the command is
|
||||
@@ -716,7 +716,7 @@ notes, and a document listing each person on the release team.
|
||||
The feature tracking sheet
|
||||
[for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases) lists each feature that is planned for a release.
|
||||
Each line item includes the name of the feature, a link to the feature's main
|
||||
Github issue, its stability level (Alpha, Beta, or Stable), the SIG and
|
||||
GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and
|
||||
individual responsible for implementing it, whether it
|
||||
needs docs, a draft release note for the feature, and whether it has been
|
||||
merged. Keep the following in mind:
|
||||
@@ -790,7 +790,7 @@ individual repositories. Many of these repositories contain code or content that
|
||||
can be considered documentation, such as user-facing help text, error messages,
|
||||
user-facing text in API references, or even code comments.
|
||||
|
||||
If you see text and you aren't sure where it comes from, you can use Github's
|
||||
If you see text and you aren't sure where it comes from, you can use GitHub's
|
||||
search tool at the level of the Kubernetes organization to search through all
|
||||
repositories for that text. This can help you figure out where to submit your
|
||||
issue or PR.
|
||||
|
||||
@@ -96,16 +96,16 @@ in the Kubernetes organization. Follow these steps:
|
||||
SIG Docs member.
|
||||
{{< /note >}}
|
||||
|
||||
2. Open a Github issue in the `kubernetes/org` repository to request membership.
|
||||
2. Open a GitHub issue in the `kubernetes/org` repository to request membership.
|
||||
Fill out the template using the guidelines at
|
||||
[Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md).
|
||||
|
||||
3. Let your sponsors know about the Github issue, either by at-mentioning them
|
||||
in the Github issue (adding a comment with `@<Github-username>`) or by sending them the link directly,
|
||||
3. Let your sponsors know about the GitHub issue, either by at-mentioning them
|
||||
in the GitHub issue (adding a comment with `@<GitHub-username>`) or by sending them the link directly,
|
||||
so that they can add a `+1` vote.
|
||||
|
||||
4. When your membership is approved, the github admin team member assigned to your request updates the
|
||||
Github issue to show approval and then closes the Github issue.
|
||||
GitHub issue to show approval and then closes the GitHub issue.
|
||||
Congratulations, you are now a member!
|
||||
|
||||
If for some reason your membership request is not accepted right away, the
|
||||
@@ -116,7 +116,7 @@ again.
|
||||
|
||||
Reviewers are members of the
|
||||
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
|
||||
Github group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
|
||||
GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
|
||||
|
||||
Reviewers review documentation pull requests and provide feedback on proposed
|
||||
changes.
|
||||
@@ -158,14 +158,14 @@ will assign and suggest you as a reviewer on new pull requests.
|
||||
|
||||
If you are approved, request that a current SIG Docs approver add you to the
|
||||
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
|
||||
Github group. Only members of the `kubernetes-website-admins` Github group can
|
||||
add new members to a Github group.
|
||||
GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
|
||||
add new members to a GitHub group.
|
||||
|
||||
### Approvers
|
||||
|
||||
Approvers are members of the
|
||||
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
|
||||
Github group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
|
||||
GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
|
||||
|
||||
Approvers have the ability to merge a PR, and thus, to publish content on the
|
||||
Kubernetes website. To approve a PR, an approver leaves an `/approve` comment on
|
||||
@@ -198,12 +198,12 @@ will assign and suggest you as a reviewer on new pull requests.
|
||||
|
||||
If you are approved, request that a current SIG Docs approver add you to the
|
||||
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
|
||||
Github group. Only members of the `kubernetes-website-admins` Github group can
|
||||
add new members to a Github group.
|
||||
GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
|
||||
add new members to a GitHub group.
|
||||
|
||||
#### Becoming a website admin
|
||||
|
||||
Members of the `kubernetes-website-admins` Github group can manage Github group
|
||||
Members of the `kubernetes-website-admins` GitHub group can manage GitHub group
|
||||
membership and have full administrative rights to the settings of the repository,
|
||||
including the ability to add, remove, and troubleshoot webhooks. Not all SIG
|
||||
Docs approvers need this level of access.
|
||||
@@ -232,16 +232,16 @@ for the current list of chairpersons.
|
||||
## SIG Docs teams and automation
|
||||
|
||||
Automation in SIG Docs relies on two different mechanisms for automation:
|
||||
Github groups and OWNERS files.
|
||||
GitHub groups and OWNERS files.
|
||||
|
||||
### Github groups
|
||||
### GitHub groups
|
||||
|
||||
The SIG Docs group defines two teams on Github:
|
||||
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)
|
||||
|
||||
Each can be referenced with their `@name` in Github comments to communicate with
|
||||
Each 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
|
||||
@@ -251,7 +251,7 @@ the automation uses information from OWNERS files.
|
||||
### OWNERS files and front-matter
|
||||
|
||||
The Kubernetes project uses an automation tool called prow for automation
|
||||
related to Github issues and pull requests. The
|
||||
related to GitHub issues and pull requests. The
|
||||
[Kubernetes website repository](https://github.com/kubernetes/website) uses
|
||||
two [prow plugins](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210):
|
||||
|
||||
@@ -261,7 +261,7 @@ two [prow plugins](https://github.com/kubernetes/test-infra/blob/master/prow/plu
|
||||
These two plugins use the
|
||||
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and
|
||||
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
|
||||
files in the top level of the `kubernetes/website` Github repository to control
|
||||
files in the top level of the `kubernetes/website` GitHub repository to control
|
||||
how prow works within the repository.
|
||||
|
||||
An OWNERS file contains a list of people who are SIG Docs reviewers and
|
||||
@@ -271,7 +271,7 @@ descendents. For more information about OWNERS files in general, see
|
||||
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
|
||||
|
||||
In addition, an individual Markdown file can list reviewers and approvers in its
|
||||
front-matter, either by listing individual Github usernames or Github groups.
|
||||
front-matter, either by listing individual GitHub usernames or GitHub groups.
|
||||
|
||||
The combination of OWNERS files and front-matter in Markdown files determines
|
||||
the advice PR owners get from automated systems about who to ask for technical
|
||||
|
||||
@@ -14,7 +14,7 @@ If you want to get started contributing to the Kubernetes documentation, this
|
||||
page and its linked topics can help you get started. You don't need to be a
|
||||
developer or a technical writer to make a big impact on the Kubernetes
|
||||
documentation and user experience! All you need for the topics on this page is
|
||||
a [Github account](https://github.com/join) and a web browser.
|
||||
a [GitHub account](https://github.com/join) and a web browser.
|
||||
|
||||
If you're looking for information on how to start contributing to Kubernetes
|
||||
code repositories, refer to
|
||||
@@ -27,12 +27,12 @@ code repositories, refer to
|
||||
|
||||
## The basics about our docs
|
||||
|
||||
The Kubernetes documentation is written in Markdown and processed and deployed using Hugo. The source is in Github at [https://github.com/kubernetes/website](https://github.com/kubernetes/website). Most of the documentation source is stored in `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
|
||||
The Kubernetes documentation is written in Markdown and processed and deployed using Hugo. The source is in GitHub at [https://github.com/kubernetes/website](https://github.com/kubernetes/website). Most of the documentation source is stored in `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
|
||||
|
||||
You can file issues, edit content, and review changes from others, all from the
|
||||
Github website. You can also use Github's embedded history and search tools.
|
||||
GitHub website. You can also use GitHub's embedded history and search tools.
|
||||
|
||||
Not all tasks can be done in the Github UI, but these are discussed in the
|
||||
Not all tasks can be done in the GitHub UI, but these are discussed in the
|
||||
[intermediate](/docs/contribute/intermediate/) and
|
||||
[advanced](/docs/contribute/advanced/) docs contribution guides.
|
||||
|
||||
@@ -78,7 +78,7 @@ If you're interested in starting a new localization, see ["Localization"](/docs/
|
||||
|
||||
## File actionable issues
|
||||
|
||||
Anyone with a Github account can file an issue (bug report) against the
|
||||
Anyone with a GitHub account can file an issue (bug report) against the
|
||||
Kubernetes documentation. If you see something wrong, even if you have no idea
|
||||
how to fix it, [file an issue](#how-to-file-an-issue). The exception to this
|
||||
rule is a tiny bug like a typo that you intend to fix yourself. In that case,
|
||||
@@ -90,7 +90,7 @@ you can instead [fix it](#improve-existing-content) without filing a bug first.
|
||||
|
||||
If you see a problem in an existing page in the [Kubernetes docs](/docs/),
|
||||
go to the bottom of the page and click the **Create an Issue** button. If
|
||||
you are not currently logged in to Github, log in. A Github issue form
|
||||
you are not currently logged in to GitHub, log in. A GitHub issue form
|
||||
appears with some pre-populated content.
|
||||
|
||||
Using Markdown, fill in as many details as you can. In places where you see
|
||||
@@ -125,7 +125,7 @@ in mind:
|
||||
- Be respectful and avoid venting. For instance, "The docs about X suck" is not
|
||||
helpful or actionable feedback. The
|
||||
[Code of Conduct](/community/code-of-conduct/) also applies to interactions on
|
||||
Kubernetes Github repositories.
|
||||
Kubernetes GitHub repositories.
|
||||
|
||||
## Participate in SIG Docs discussions
|
||||
|
||||
@@ -145,7 +145,7 @@ You can also check the SIG Docs weekly meeting on the [Kubernetes community meet
|
||||
## Improve existing content
|
||||
|
||||
To improve existing content, you file a _pull request (PR)_ after creating a
|
||||
_fork_. Those two terms are [specific to Github](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/).
|
||||
_fork_. Those two terms are [specific to GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/).
|
||||
For the purposes of this topic, you don't need to know everything about them,
|
||||
because you can do everything using your web browser. When you continue to the
|
||||
[intermediate docs contributor guide](/docs/contribute/intermediate/), you will
|
||||
@@ -201,9 +201,9 @@ Follow these steps to submit a pull request to improve the Kubernetes
|
||||
documentation.
|
||||
|
||||
1. On the page where you see the issue, click the pencil icon at the top right.
|
||||
A new Github page appears, with some help text.
|
||||
A new GitHub page appears, with some help text.
|
||||
2. If you have never created a fork of the Kubernetes documentation
|
||||
repository, you are prompted to do so. Create the fork under your Github
|
||||
repository, you are prompted to do so. Create the fork under your GitHub
|
||||
username, rather than another organization you may be a member of. The
|
||||
fork usually has a URL such as `https://github.com/<username>/website`,
|
||||
unless you already have a repository with a conflicting name.
|
||||
@@ -211,14 +211,14 @@ documentation.
|
||||
The reason you are prompted to create a fork is that you do not have
|
||||
access to push a branch directly to the definitive Kubernetes repository.
|
||||
|
||||
3. The Github Markdown editor appears with the source Markdown file loaded.
|
||||
3. The GitHub Markdown editor appears with the source Markdown file loaded.
|
||||
Make your changes. Below the editor, fill in the **Propose file change**
|
||||
form. The first field is the summary of your commit message and should be
|
||||
no more than 50 characters long. The second field is optional, but can
|
||||
include more detail if appropriate.
|
||||
|
||||
{{< note >}}
|
||||
Do not include references to other Github issues or pull
|
||||
Do not include references to other GitHub issues or pull
|
||||
requests in your commit message. You can add those to the pull request
|
||||
description later.
|
||||
{{< /note >}}
|
||||
@@ -238,7 +238,7 @@ description later.
|
||||
{{< note >}}
|
||||
If you don't want to create the pull request now, you can do it
|
||||
later, by browsing to the main URL of the Kubernetes website repository or
|
||||
your fork's repository. The Github website will prompt you to create the
|
||||
your fork's repository. The GitHub website will prompt you to create the
|
||||
pull request if it detects that you pushed a new branch to your fork.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -268,8 +268,8 @@ pull request if it detects that you pushed a new branch to your fork.
|
||||
change is live on the Kubernetes website a few minutes later.
|
||||
|
||||
This is only one way to submit a pull request. If you are already a Git and
|
||||
Github advanced user, you can use a local GUI or command-line Git client
|
||||
instead of using the Github UI. Some basics about using the command-line Git
|
||||
GitHub advanced user, you can use a local GUI or command-line Git client
|
||||
instead of using the GitHub UI. Some basics about using the command-line Git
|
||||
client are discussed in the [intermediate](/docs/contribute/intermediate/) docs
|
||||
contribution guide.
|
||||
|
||||
@@ -332,7 +332,7 @@ or follow the steps below.
|
||||
the blog post, but don't put the date in the file name. The blog reviewers
|
||||
will work with you on the final file name and the date the blog will be
|
||||
published.
|
||||
5. When you save the file, Github will walk you through the pull request
|
||||
5. When you save the file, GitHub will walk you through the pull request
|
||||
process.
|
||||
6. A blog post reviewer will review your submission and work with you on
|
||||
feedback and final details. When the blog post is approved, the blog will be
|
||||
|
||||
@@ -46,6 +46,6 @@ Placeholder text is included.
|
||||
## Submitting new snippets
|
||||
|
||||
1. Develop the snippet locally and verify that it works as expected.
|
||||
2. Copy the template's code into the `atom-snippets.cson` file on Github. Raise a
|
||||
2. Copy the template's code into the `atom-snippets.cson` file on GitHub. Raise a
|
||||
pull request, and ask for review from another Atom user in `#sig-docs` on
|
||||
Kubernetes Slack.
|
||||
@@ -617,7 +617,7 @@ control of your Kubernetes cluster.
|
||||
|
||||
## Feedback {#feedback}
|
||||
|
||||
* For bugs, visit [kubeadm Github issue tracker](https://github.com/kubernetes/kubeadm/issues)
|
||||
* For bugs, visit [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
|
||||
* For support, visit kubeadm Slack Channel:
|
||||
[#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
|
||||
* General SIG Cluster Lifecycle Development Slack Channel:
|
||||
|
||||
@@ -515,7 +515,7 @@ If these steps don't resolve your problem, you can get help running Windows cont
|
||||
|
||||
## Reporting Issues and Feature Requests
|
||||
|
||||
If you have what looks like a bug, or you would like to make a feature request, please use the [Github issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket.
|
||||
If you have what looks like a bug, or you would like to make a feature request, please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket.
|
||||
|
||||
If filing a bug, please include detailed information about how to reproduce the problem, such as:
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ in the Kubernetes source directory for a canonical example.
|
||||
|
||||
Package your scheduler binary into a container image. For the purposes of this example,
|
||||
let's just use the default scheduler (kube-scheduler) as our second scheduler as well.
|
||||
Clone the [Kubernetes source code from Github](https://github.com/kubernetes/kubernetes)
|
||||
Clone the [Kubernetes source code from GitHub](https://github.com/kubernetes/kubernetes)
|
||||
and build the source.
|
||||
|
||||
```shell
|
||||
|
||||
@@ -90,7 +90,7 @@ The Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes
|
||||
### Bugs and Feature requests
|
||||
|
||||
If you have what looks like a bug, or you would like to make a feature request,
|
||||
please use the [Github issue tracking system](https://github.com/kubernetes/kubernetes/issues).
|
||||
please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues).
|
||||
|
||||
Before you file an issue, please search existing issues to see if your issue is
|
||||
already covered.
|
||||
|
||||
Reference in New Issue
Block a user