Deployment of the hubs is managed with continuous integration (TravisCI), rather than through use of the command-line kubernetes tools. Pull requests to the master branch trigger travis, as does merging a pull request. The Travis steps are scripted using python rather than calling kubectl and helm directly.

User workflow

When making changes to a hub (including both Deploying New Hubs and Manage, Modify or Remove a Hub), the expected workflow is:

  • change the required settings in this repo (e.g. the helm charts in hub-charts, or the Dockerfiles in user-images)

  • create a pull request with your changes - this will initiate a travis run that tests the builds of the docker image(s) and the docs. This does not push to Dockerhub, and does not deploy the hub. More specifically, this build skips the before_deploy and deploy sections in .travis.yml.

  • after the PR is merged, travis builds the docker image(s), pushes them to dockerhub, and deploys the hub(s). This build runs the before_deploy and deploy sections in .travis.yml.

Before making changes to a production hub (i.e. one being used for a course), test your changes on staginghub and only when that deploys correctly, copy these changes to the production hub.

Deploy script

The script at the top-level of this repo manages docker builds and deployments. The expectation is that this is only called by travis, not directly by the user (see the workflow, below).

Basic usage is python chartname. The following options are available:

  • --no-setup : run without setup procedures (authentication to GCloud and docker, helm / tiller status)

  • --build : build docker images; see Customize Your Hub for setting these up

  • --push : push images to dockerhub (option ignored if build==False)

  • --deploy : deploy the hub

These are the commands that runs when deploying a hub :

helm dependency update <chartname>
helm upgrade --install --namespace <chartname> <chartname> <chart_dir> --force --wait --timeout 600 --cleanup-on-fail -f <secret>

Then, for each deployments found with kubectl -n <chartname> get deployments -o name:

kubectl rollout status --namespace <chartname> --watch <deployment>


If you do run locally, use the --no-setup flag to avoid authenticating to gcloud as the travis user and borking your local access to the cluster. If that does happen, you can delete your .kube directory and re-authenticate to gcloud.