This document explains how to get started with developing for NGINX Ingress controller. It includes how to build, test, and release ingress controllers.
The build uses dependencies in the vendor
directory, which
must be installed before building a binary/image. Occasionally, you
might need to update the dependencies.
This guide requires you to install the dep dependency tool.
Check the version of dep
you are using and make sure it is up to date.
$ dep version
dep:
version : devel
build date :
git hash :
go version : go1.9
go compiler : gc
platform : linux/amd64
If you have an older version of dep
, you can update it as follows:
$ go get -u github.com/golang/dep
This will automatically save the dependencies to the vendor/
directory.
$ cd $GOPATH/src/k8s.io/ingress-nginx
$ dep ensure
$ dep ensure -update
$ dep prune
All ingress controllers are built through a Makefile. Depending on your requirements you can build a raw server binary, a local container image, or push an image to a remote repository.
In order to use your local Docker, you may need to set the following environment variables:
# "gcloud docker" (default) or "docker"
$ export DOCKER=<docker>
# "quay.io/kubernetes-ingress-controller" (default), "index.docker.io", or your own registry
$ export REGISTRY=<your-docker-registry>
To find the registry simply run: docker system info | grep Registry
Build a raw server binary
$ make build
TODO: add more specific instructions needed for raw server binary.
Build a local container image
$ TAG=<tag> REGISTRY=$USER/ingress-controller make docker-build
Push the container image to a remote repository
$ TAG=<tag> REGISTRY=$USER/ingress-controller make docker-push
There are several ways to deploy the ingress controller onto a cluster. Please check the deployment guide
To run unit-tests, just run
$ cd $GOPATH/src/k8s.io/ingress-nginx
$ make test
If you have access to a Kubernetes cluster, you can also run e2e tests using ginkgo.
$ cd $GOPATH/src/k8s.io/ingress-nginx
$ make e2e-test
All Makefiles will produce a release binary, as shown above. To publish this
to a wider Kubernetes user base, push the image to a container registry, like
gcr.io. All release images are hosted under gcr.io/google_containers
and
tagged according to a semver scheme.
An example release might look like:
$ make release
Please follow these guidelines to cut a release:
- Update the release page with a short description of the major changes that correspond to a given image tag.
- Cut a release branch, if appropriate. Release branches follow the format of
controller-release-version
. Typically, pre-releases are cut from HEAD. All major feature work is done in HEAD. Specific bug fixes are cherry-picked into a release branch. - If you're not confident about the stability of the code, tag it as alpha or beta. Typically, a release branch should have stable code.