CI: Automated build/release workflow (#46)

TLDR; Run "make help" for options.

* gofmt
* .gitignore kube-router binary
* Docs: build/release workflow
* Implement build/release workflow

Author: bzub

.gitignore

@@ -0,0 +1 @@
+/kube-router

.goreleaser.yml

@@ -0,0 +1,18 @@
+builds:
+- goos:
+  - linux
+  goarch:
+  - amd64
+  env:
+  - CGO_ENABLED=0
+archive:
+  format: tar.gz
+  name_template: '{{ .Binary }}_{{.Version}}_{{ .Os }}_{{ .Arch }}{{ if .Arm }}v{{
+    .Arm }}{{ end }}'
+  files:
+  - LICENSE*
+  - README*
+  - CHANGELOG*
+  - Documentation*
+snapshot:
+  name_template: SNAPSHOT-{{ .Commit }}

.travis.yml

@@ -2,21 +2,46 @@ services:
   - docker
 
 language: go
-go: 
+go:
   - 1.7.x
 
 env:
-  - REPO=cloudnativelabs/kube-router
-after_success:
-    - docker login -u="$DOCKER_USERNAME" -p="$DOCKER_PASSWORD";
-    - export TAG=`if [ "$TRAVIS_BRANCH" == "master" ]; then echo "master"; else echo $TRAVIS_BRANCH ; fi`
-    - docker build -f Dockerfile -t "$REPO":"$TRAVIS_COMMIT" .
-    - docker tag "$REPO":"$TRAVIS_COMMIT" "$REPO":"$TAG"
-    - if [ ! -z ${TRAVIS_TAG+x} ]; then
-          docker tag "$REPO":"$TRAVIS_COMMIT" "$REPO":"$TRAVIS_TAG";
-          docker tag "$REPO":"$TRAVIS_COMMIT" "$REPO":"latest";
-      fi
-    - docker push "$REPO"
- 
+  global:
+    - IMG_FQDN=quay.io
+    - REPO=cloudnativelabs/kube-router
+    - REPO_PATH=$HOME/gopath/src/github.com/$REPO
+
 script:
- - make all 
+  - make all
+
+after_success:
+  # All successfully built commits get an image placed in the kube-router-git
+  # image repo and tagged with the commit hash.
+  - make push
+
+deploy:
+  # Images from Pull Requests get tagged with the PR number.
+  - provider: script
+    on:
+      condition: $TRAVIS_PULL_REQUEST != "false"
+    skip_cleanup: true
+    script:
+      - make push IMG_PREFIX=PR$TRAVIS_PULL_REQUEST-
+
+  # Images from tagged commits get released.
+  - provider: script
+    on:
+      tags: true
+      # condition: $TRAVIS_PULL_REQUEST == "false"
+    skip_cleanup: true
+    script:
+      - unset IMG_FQDN # Use DockerHub for releases
+      - make release
+
+# This fixes issues when a contributor uses their own Travis CI account to test
+# code/CI changes.
+before_install:
+  - mkdir -p $REPO_PATH
+  - rsync -az ${TRAVIS_BUILD_DIR}/ $REPO_PATH
+  - export TRAVIS_BUILD_DIR=$REPO_PATH
+  - cd $REPO_PATH

CONTRIBUTING.md

@@ -11,11 +11,13 @@ Please read [users guide](./Documentation/README.md#user-guide) and [developers
 
 If you have a question about Kube-router or have a problem using it, please start with contacting us on [community forum](https://gitter.im/kube-router/Lobby) for quick help. If that doesn't answer your questions, or if you think you found a bug, please [file an issue](https://github.com/cloudnativelabs/kube-router/issues).
 
-## Submit PR
+## Contributing Changes
 
 ### Fork the code
 
-Navigate to: [https://github.com/cloudnativelabs/kube-router](https://github.com/cloudnativelabs/kube-router) fork the repository.
+Navigate to:
+[https://github.com/cloudnativelabs/kube-router](https://github.com/cloudnativelabs/kube-router)
+and fork the repository.
 
 Follow these steps to setup a local repository for working on Kube-router:
 
@@ -28,7 +30,7 @@ $ git fetch upstream
 $ git rebase upstream/master
 ```
 
-### Making changes and raising PR
+### Creating A Feature Branch
 
 Create a new branch to make changes on and that branch.
 
@@ -51,6 +53,8 @@ $ git rebase master
 
 Now your `feature_x` branch is up-to-date with all the code in `upstream/master`, so push to your fork
 
+### Performing A Pull Request
+
 ``` bash
 $ git push origin master
 $ git push origin feature_x

Documentation/README.md

@@ -176,13 +176,6 @@ To enable hairpin traffic for Service `my-service`:
 kubectl annotate service my-service 'kube-router.io/hairpin-mode='
 ```
 
-## Develope Guide
-
-**Go version 1.7 or above is required to build kube-router**
-
-All the dependencies are vendored already, so just run  *make build* or *go build -o kube-router kube-router.go* to build
-
-Alternatively you can download the prebuilt binary from https://github.com/cloudnativelabs/kube-router/releases
 
 ## BGP configuration
 

Documentation/developing.md

@@ -0,0 +1,155 @@
+# Developer's Guide
+
+We aim to make local development and testing as straightforward as possible. For
+basic guidelines around contributing, see the [CONTRIBUTING](/CONTRIBUTING.md) document.
+
+There are a number of automation tools available to help with testing and
+building your changes, detailed below.
+
+## Building kube-router
+
+**Go version 1.7 or above is required to build kube-router**
+
+All the dependencies are vendored already, so just run `make` or `go build -o kube-router kube-router.go` to build.
+
+### Building A Docker Image
+
+Running `make container` will compile kube-router (if needed) and build a Docker
+image.  By default the container will be tagged with the last release version,
+and current commit ID.
+
+For example:
+```console
+$ make container
+docker build -t "cloudnativelabs/kube-router-git:0.0.4-22-gd782e89-dirty-build-release"
+Sending build context to Docker daemon  151.5MB
+Step 1/4 : FROM alpine
+ ---> a41a7446062d
+Step 2/4 : RUN apk add --no-cache iptables ipset
+ ---> Using cache
+ ---> 30e25a7640de
+Step 3/4 : COPY kube-router /
+ ---> Using cache
+ ---> c06f78fd02e8
+Step 4/4 : ENTRYPOINT /kube-router
+ ---> Using cache
+ ---> 5cfcfe54623e
+Successfully built 5cfcfe54623e
+Successfully tagged cloudnativelabs/kube-router-git:0.0.4-22-gd782e89-dirty-build-release
+```
+
+The `-dirty` part of the tag means there are uncommitted changes in your local
+git repo.
+
+### Pushing A Docker Image
+
+Running `make push` will push your container image to a Docker registry.  The
+default configuration will use the Docker Hub repository for the official
+kube-router images, cloudnativelabs/kube-router. You can push to a different
+repository by changing a couple settings, as described in [Image Options](#image-options)
+below.
+
+### Makefile Options
+
+There are several variables which can be modified in the Makefile to customize
+your builds. They are specified after your make command like this: `make OPTION=VALUE`.
+These options can also be set in your environment variables.
+For more details beyond the scope of this document, see the
+[Makefile](/Makefile) and run `make help`.
+
+#### Image Options
+
+You can configure the name and tag of the Docker image with a few variables
+passed to `make container` and `make push`.
+
+Example:
+```console
+$ make container IMG_FQDN=quay.io IMG_NAMESPACE=bzub IMAGE_TAG=custom
+docker build -t "quay.io/bzub/kube-router-git:custom" .
+Sending build context to Docker daemon  151.5MB
+Step 1/4 : FROM alpine
+ ---> a41a7446062d
+Step 2/4 : RUN apk add --no-cache iptables ipset
+ ---> Using cache
+ ---> 30e25a7640de
+Step 3/4 : COPY kube-router /
+ ---> Using cache
+ ---> c06f78fd02e8
+Step 4/4 : ENTRYPOINT /kube-router
+ ---> Using cache
+ ---> 5cfcfe54623e
+Successfully built 5cfcfe54623e
+Successfully tagged quay.io/bzub/kube-router-git:custom
+```
+
+- `REGISTRY` is derived from other options. Set this to something else to
+  quickly override the Docker image registry used to tag and push images.
+  - Note: This will override other variables below that make up the image
+    name/tag.
+- `IMG_FQDN` should be set if you are not using Docker Hub for images. In
+  the examples above `IMG_FQDN` is set to `quay.io`.
+- `IMG_NAMESPACE` is the Docker registry user or organization.  It is used in
+  URLs.
+  - Example: quay.io/IMG_NAMESPACE/kube-router
+- `NAME` goes onto the end of the Docker registry URL that will be used.
+  - Example: quay.io/cloudnativelabs/NAME
+- `IMAGE_TAG` is used to override the tag of the Docker image being built.
+- `DEV_SUFFIX` is appended to Docker image names that are not for release.  By
+  default these images get a name ending with `-git` to signify that they are
+  for testing purposes.
+  Example (DEV-SUFFIX=master-latest): quay.io/cloudnativelabs/kube-router-git:master-latest
+
+## Release Workflow
+
+These instructions show how official kube-router releases are performed.
+
+First, you must tag a git commit with the release version.
+This will cause the CI system to:
+- Build kube-router
+- Build a Docker image with ${VERSION} and `latest` tags
+- Push the Docker image to the official registry
+- Submits a draft release to GitHub
+
+Example:
+```
+VERSION=v0.5.0
+git tag -a ${VERSION} -m "Brief release note" && git push origin ${VERSION}
+```
+
+Then the only thing left to do is edit the release notes on the GitHub release
+and publish it.
+
+### Manual Releases
+
+These instructions show how To perform a custom or test release outside of the
+CI system, using a local git commit.
+
+First tag a commit:
+```
+VERSION=v0.5.0_bzub
+git tag -a ${VERSION} -m "Brief release note"
+```
+
+Then you can provide
+[options](#makefile-options) to `make release`.
+
+This does the following:
+- Builds kube-router
+- Builds a Docker image
+- Tags the image with the current git commit's tag
+- Tags the image with `latest`
+- Pushes the image to a docker registry
+
+If you'd like to test the GitHub release functionality as well, you will need to
+pass in the `GITHUB_TOKEN` variable with a value of an API token you've
+[generated](https://github.com/settings/tokens/new). This Access Token must have
+the "repo" OAuth scope enabled.
+
+NOTE: For added security when running a command that contains secure
+credentials, add a space before the entire command to prevent it from being
+added to your shell history file.
+
+Example:
+```console
+$  make release IMG_FQDN=quay.io IMG_NAMESPACE=bzub GITHUB_TOKEN=b1ahbl1ahb1ahba1hahb1ah
+```