Skip to content

Commit

Permalink
Merge pull request kubernetes#1555 from guineveresaenger/github-workflow
Browse files Browse the repository at this point in the history 
moved Github workflow and diagram to contributors/guide folder and re…
  • Loading branch information
@k8s-ci-robot
k8s-ci-robot authored Jan 3, 2018
2 parents cb31513 + 73abfab commit 32cf22b
Show file tree
Hide file tree
Showing 4 changed files with 232 additions and 235 deletions.
230 changes: 2 additions & 228 deletions contributors/devel/development.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -166,235 +166,9 @@ Building with Bazel is currently experimental. For more information,
see [Build with Bazel].


## Workflow
## GitHub workflow

![Git workflow](git_workflow.png)

### 1 Fork in the cloud

1. Visit https://github.com/kubernetes/kubernetes
2. Click `Fork` button (top right) to establish a cloud-based fork.

### 2 Clone fork to local storage

Per Go's [workspace instructions][go-workspace], place Kubernetes' code on your
`GOPATH` using the following cloning procedure.

Define a local working directory:

```sh
# If your GOPATH has multiple paths, pick
# just one and use it instead of $GOPATH here.
# You must follow exactly this pattern,
# neither `$GOPATH/src/github.com/${your github profile name/`
# nor any other pattern will work.
working_dir=$GOPATH/src/k8s.io
```

> If you already do Go development on github, the `k8s.io` directory
> will be a sibling to your existing `github.com` directory.
Set `user` to match your github profile name:

```sh
user={your github profile name}
```

Both `$working_dir` and `$user` are mentioned in the figure above.

Create your clone:

```sh
mkdir -p $working_dir
cd $working_dir
git clone https://github.com/$user/kubernetes.git
# or: git clone [email protected]:$user/kubernetes.git

cd $working_dir/kubernetes
git remote add upstream https://github.com/kubernetes/kubernetes.git
# or: git remote add upstream [email protected]:kubernetes/kubernetes.git

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

# Confirm that your remotes make sense:
git remote -v
```

### 3 Branch

Get your local master up to date:

```sh
cd $working_dir/kubernetes
git fetch upstream
git checkout master
git rebase upstream/master
```

Branch from it:
```sh
git checkout -b myfeature
```

Then edit code on the `myfeature` branch.

#### Build

*Note:* If you are using `CDPATH`, you must either start it with a leading colon, or unset the variable. The make rules and scripts to build require the current directory to come first on the CD search path in order to properly navigate between directories.

```sh
cd $working_dir/kubernetes
make
```

To remove the limit on the number of errors the Go compiler reports (default
limit is 10 errors):
```sh
make GOGCFLAGS="-e"
```

To build with optimizations disabled (enables use of source debug tools):

```sh
make GOGCFLAGS="-N -l"
```

To build binaries for all platforms:

```sh
make cross
```

#### Install etcd

```sh
hack/install-etcd.sh
```

#### Test

```sh
cd $working_dir/kubernetes

# Run all the presubmission verification. Then, run a specific update script (hack/update-*.sh)
# for each failed verification. For example:
# hack/update-gofmt.sh (to make sure all files are correctly formatted, usually needed when you add new files)
# hack/update-bazel.sh (to update bazel build related files, usually needed when you add or remove imports)
make verify

# Alternatively, run all update scripts to avoid fixing verification failures one by one.
make update

# Run every unit test
make test

# Run package tests verbosely
make test WHAT=./pkg/api/helper GOFLAGS=-v

# Run integration tests, requires etcd
# For more info, visit https://git.k8s.io/community/contributors/devel/testing.md#integration-tests
make test-integration

# Run e2e tests by building test binaries, turn up a test cluster, run all tests, and tear the cluster down
# Equivalent to: go run hack/e2e.go -- -v --build --up --test --down
# Note: running all e2e tests takes a LONG time! To run specific e2e tests, visit:
# https://git.k8s.io/community/contributors/devel/e2e-tests.md#building-kubernetes-and-running-the-tests
make test-e2e
```

See the [testing guide](testing.md) and [end-to-end tests](e2e-tests.md)
for additional information and scenarios.

Run `make help` for additional information on these make targets.

### 4 Keep your branch in sync

```sh
# While on your myfeature branch
git fetch upstream
git rebase upstream/master
```

Please don't use `git pull` instead of the above `fetch` / `rebase`. `git pull`
does a merge, which leaves merge commits. These make the commit history messy
and violate the principle that commits ought to be individually understandable
and useful (see below). You can also consider changing your `.git/config` file via
`git config branch.autoSetupRebase always` to change the behavior of `git pull`.

### 5 Commit

Commit your changes.

```sh
git commit
```
Likely you go back and edit/build/test some more then `commit --amend`
in a few cycles.

### 6 Push

When ready to review (or just to establish an offsite backup or your work),
push your branch to your fork on `github.com`:

```sh
git push -f ${your_remote_name} myfeature
```

### 7 Create a pull request

1. Visit your fork at https://github.com/$user/kubernetes
2. Click the `Compare & Pull Request` button next to your `myfeature` branch.
3. Check out the pull request [process](pull-requests.md) for more details and
advice.

_If you have upstream write access_, please refrain from using the GitHub UI for
creating PRs, because GitHub will create the PR branch inside the main
repository rather than inside your fork.

#### Get a code review

Once your pull request has been opened it will be assigned to one or more
reviewers. Those reviewers will do a thorough code review, looking for
correctness, bugs, opportunities for improvement, documentation and comments,
and style.

Commit changes made in response to review comments to the same branch on your
fork.

Very small PRs are easy to review. Very large PRs are very difficult to review.
At the assigned reviewer's discretion, a PR may be switched to use
[Reviewable](https://reviewable.k8s.io) instead. Once a PR is switched to
Reviewable, please ONLY send or reply to comments through Reviewable. Mixing
code review tools can be very confusing.

#### Squash and Merge

Upon merge (by either you or your reviewer), all commits left on the review
branch should represent meaningful milestones or units of work. Use commits to
add clarity to the development and review process.

Before merging a PR, squash any _fix review feedback_, _typo_, _merged_, and
_rebased_ sorts of commits.

It is not imperative that every commit in a PR compile and pass tests
independently, but it is worth striving for.

In particular, if you happened to have used `git merge` and have merge
commits, please squash those away: they do not meet the above test.

A nifty way to manage the commits in your PR is to do an [interactive
rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History),
which will let you tell git what to do with every commit:

```sh
git fetch upstream
git rebase -i upstream/master
```

For mass automated fixups (e.g. automated doc formatting), use one or more
commits for the changes to tooling and a final commit to apply the fixup en
masse. This makes reviews easier.
To check out code to work on, please refer to [this guide](/contributors/guide/github-workflow.md).


[OS X GNU tools]: https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x
Expand Down
8 changes: 1 addition & 7 deletions contributors/guide/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,6 @@ Please find _Improvements needed_ sections below and help us out.
For example:

_Improvements needed_
* kubernetes/kubernetes/contributing.md -> point to this guide

* kubernetes/community/CONTRIBUTING.md -> Needs a rewrite

* kubernetes/community/README.md -> Needs a rewrite
Expand Down Expand Up @@ -157,11 +155,7 @@ For questions and troubleshooting, please feel free to use any of the methods of

## GitHub workflow

To check out code to work on, please refer to [this guide](/contributors/devel/development.md#workflow).

_Improvements needed_

* move github workflow into its own file in this folder.
To check out code to work on, please refer to [this guide](/github-workflow.md).

## Open a Pull Request

Expand Down
0 contributors/devel/git_workflow.png → contributors/guide/git_workflow.png
View file
File renamed without changes
Loading

0 comments on commit 32cf22b

Please sign in to comment.