Add golang 1.10 to supported list, minor updates to dev flow instructions

Signed-off-by: Jared Watts <jbw976@gmail.com>
2018-02-26 14:41:28 -08:00
1 parent d90564df12
commit c35754ece8
@@ -32,7 +32,7 @@ mkdir -p $GOPATH/src/github.com/rook
 cd $GOPATH/src/github.com/rook

 # Clone your fork, where <user> is your github account name
-git clone git@github.com:<user>/rook.git
+git clone https://github.com/<user>/rook.git

 cd rook

@@ -62,11 +62,12 @@ To add a feature or to make a bug fix, you will need to create a branch in your
 From a console, create a new branch based on your fork and start working on it:

 ```bash
-# Checkout the master branch - you want your new branch to come from master
-git checkout master
+# Ensure all your remotes are up to date with the latest
+git fetch --all

-# Create a new branch with a simple, but descriptive name. Generally it will be two to three words separated by dashes and without numbers.
-git checkout -b feature-name
+# Create a new branch that is based off upstream master.  Give it a simple, but descriptive name.
+# Generally it will be two to three words separated by dashes and without numbers.
+git checkout -b feature-name upstream/master
 ```

 Now you are ready to make the changes and commit to your branch.
@@ -75,9 +76,10 @@ Now you are ready to make the changes and commit to your branch.

 During the development lifecycle, you will need to keep up-to-date with the latest upstream master. As others on the team push changes, you will need to `rebase` your commits on top of the latest. This avoids unnecessary merge commits and keeps the commit history clean.

-Whenever you need to update your local repository, you never want to merge. You **always** will rebase. Otherwise you will end up with merge commits in the git history. If you have any modified files, you will first have to stash them (`git stash save "<some description>"`).
+Whenever you need to update your local repository, you never want to merge. You **always** will rebase. Otherwise you will end up with merge commits in the git history. If you have any modified files, you will first have to stash them (`git stash save -u "<some description>"`).

 ```bash
+git fetch --all
 git rebase upstream/master
 ```

@@ -98,7 +100,7 @@ In order to open a pull request (PR) it is required to be up to date with the la

 All pull requests must pass the unit and e2e smoke tests before they can be merged. These tests automatically
 run as a part of the build process. The results of these tests along with code reviews and other criterias determine whether
-your request will be accepted into the rook/rook repo. It is prudent to run all tests locally on your development box prior to submitting a pull request to the rook/rook repo.
+your request will be accepted into the `rook/rook` repo. It is prudent to run all tests locally on your development box prior to submitting a pull request to the `rook/rook` repo.

 #### Unit Tests

@@ -36,12 +36,6 @@ make -j4 build.all

 See instructions below for setting up the build environment to support `arm` and `arm64` platforms.

-Or if you wanted to build all release artifacts run:
-
-```
-make -j4 release
-```
-
 Run `make help` for more options.

 ## Building inside the cross container
@@ -49,7 +49,7 @@ GO_TEST_FLAGS ?=
 # ====================================================================================
 # Setup go environment

-GO_SUPPORTED_VERSIONS ?= 1.7|1.8|1.9
+GO_SUPPORTED_VERSIONS ?= 1.7|1.8|1.9|1.10

 GO_PACKAGES := $(foreach t,$(GO_SUBDIRS),$(GO_PROJECT)/$(t)/...)
 GO_INTEGRATION_TEST_PACKAGES := $(foreach t,$(GO_INTEGRATION_TESTS_SUBDIRS),$(GO_PROJECT)/$(t)/integration)
@@ -37,8 +37,8 @@ RUN DEBIAN_FRONTEND=noninteractive apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

 # install go-lang from the official repo
-RUN GO_VERSION=1.9.2 && \
-    GO_HASH=de874549d9a8d8d8062be05808509c09a88a248e77ec14eb77453530829ac02b && \
+RUN GO_VERSION=1.10 && \
+    GO_HASH=b5a64335f1490277b585832d1f6c7f8c6c11206cba5cd3f771dcb87b98ad1a33 && \
    curl -fsSL https://golang.org/dl/go${GO_VERSION}.linux-amd64.tar.gz -o golang.tar.gz && \
    echo "${GO_HASH}  golang.tar.gz" | sha256sum -c - && \
    tar -C /usr/local -xzf golang.tar.gz && \
@@ -13,41 +13,62 @@ quickly spin up a kubernetes cluster.The Test framework is designed to install R

 ## Instructions

-### Setup
+## Setup

-#### Install Kubernetes
+### Install Kubernetes
 You can choose any kubernetes flavor of your choice.  The test framework only depends on kubectl being configured. 
 The framework also provides scripts to install Kubernetes. There are two scripts to start the cluster:
 1. **Minikube** (recommended for MacOS): Run [minikube.sh](/tests/scripts/minikube.sh) to setup a single-node Minikube kubernetes.
    1. Minikube v0.21.0 and higher is supported. Older minikube versions do not have cephfs or rbd tools installed.
    1. If using Kubernetes v1.7.3 or higher, then Minikube v0.22.2 or higher is required.
-1. **Kubeadm** (recommended for ubuntu): run [kubeadm.sh](/tests/scripts/kubeadm.sh) to setup a single-node K8s cluster using kubeadm
+1. **Kubeadm** (recommended for Ubuntu): run [kubeadm.sh](/tests/scripts/kubeadm.sh) to setup a single-node K8s cluster using kubeadm

-These start-up scripts are designed to start any version of kubernetes, Based on `KUBE_VERSION` environment variable
-By default they start kubernetes version v1.7.5.
-e.g. To kubernetes version v1.6.7
-```
-export KUBE_VERSION=v1.6.7
-tests/scripts/kubeadm.sh up
+#### Minikube (recommended for MacOS)
+Starting the cluster on Minikube is as simple as running:
+```console
+tests/scripts/minikube.sh up
 ```

-To stop the cluster : `tests/scripts/kubeadm.sh clean` or `tests/scripts/miniube.sh clean`
-  
-To copy rook images generated by build into minikube vm, run the following commands after `minikube.sh up`
+To copy Rook images generated from your local build into the Minikube VM, run the following commands after `minikube.sh up` succeeded:
 ```
 tests/scripts/minikube.sh update
 tests/scripts/minikube.sh helm
 ```
-kubeadm.sh starts kubernetes  on the host, so all the images generated by build should be available to the cluster.

+Stopping the cluster and destroying the Minikube VM can be done with:
+```console
+tests/scripts/miniube.sh clean
+```
+
+#### Kubeadm (recommended for Ubuntu)
+Starting the cluster using `kubeadm` is as simple as running:
+```console
+tests/scripts/kubeadm.sh up
+```
+
+`kubeadm.sh` starts Kubernetes on the host, so all the images generated by your local build should be available to the cluster without any additional commands.
+
+Stopping the cluster can be done with:
+```console
+tests/scripts/kubeadm.sh clean
+```
+
+#### Alternate Kubernetes Versions
+These two scripts can install any version of Kubernetes you wish based on the `KUBE_VERSION` environment variable.
+To use an alternate version, simply set this variable before running the relevant `up` command from above.
+For example, if you wanted to use `v1.6.7`, you would run `export KUBE_VERSION=v1.6.7` first before running `up`.
+
+By default, the following versions of Kubernetes are used:
+* `minikube.sh`: `v1.9.1`
+* `kubeadm.sh`: `v1.8.5`

 ### Install Helm
-Use [helm.sh](/tests/scripts/helm.sh) to install helm and set up rook charts defined under `_output/charts` (generated by build). 
+Use [helm.sh](/tests/scripts/helm.sh) to install helm and set up rook charts defined under `_output/charts` (generated by build).
 - To install and set up Helm charts for rook run `tests/scripts/helm.sh up` 
 - To clean up `tests/scripts/helm.sh clean`

 **Note:**  *kubeadm.sh, minikube.sh and helm.sh scripts depend on some artifacts under _output dir generated during build time, these scripts 
-should be run from project root. eg* `tests/script/kubeadm.sh up`
+should be run from project root. e.g., `tests/script/kubeadm.sh up`

 ## Run Tests
 From the project root do the following: