diff --git a/Documentation/development-flow.md b/Documentation/development-flow.md index 03a978713..11961ccc9 100644 --- a/Documentation/development-flow.md +++ b/Documentation/development-flow.md @@ -32,7 +32,7 @@ mkdir -p $GOPATH/src/github.com/rook cd $GOPATH/src/github.com/rook # Clone your fork, where is your github account name -git clone git@github.com:/rook.git +git clone https://github.com//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 ""`). +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 ""`). ```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 diff --git a/INSTALL.md b/INSTALL.md index ecacdf5c9..8ac33e44e 100644 --- a/INSTALL.md +++ b/INSTALL.md @@ -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 diff --git a/build/makelib/golang.mk b/build/makelib/golang.mk index ff3116885..ce3e76425 100644 --- a/build/makelib/golang.mk +++ b/build/makelib/golang.mk @@ -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) diff --git a/images/cross/Dockerfile b/images/cross/Dockerfile index c5ec8dd05..191c01453 100644 --- a/images/cross/Dockerfile +++ b/images/cross/Dockerfile @@ -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 && \ diff --git a/tests/README.md b/tests/README.md index 4104f6a92..740891eb0 100644 --- a/tests/README.md +++ b/tests/README.md @@ -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: