Contains a fully reproducible configuration for JupyterHub on datahub.berkeley.edu, as well as its single user image.

The staging branch always reflects the state of the staging JupyterHub, and the prod branch reflects the state of the production JupyterHub.

To make changes, fork this repo and create a pull request. The choice for base in the GitHub PR user interface should be the staging branch of this repo while the choice for head is your fork. The pull request will trigger a Travis CI process and potentially a rebuild of docker images depending on what modifications have been proposed. You can observe the status of the CI process by visiting its link on the page for your PR, or by finding it on Travis' build list.

Once this is complete and if there are no problems, you can request that someone review the PR before merging, or you can merge yourself if you are confident. This merge will trigger another Travis step which upgrades the helm deployment on the staging site. When this is complete, test your changes there. For example if you updated a library, make sure that a new user server instance has the new version. If you spot any problems you can revert your change. You should test the changes soon after the merge since we do not want unverified changes to linger in staging.

If staging fails, never update production. Revert your change or call in help if necessary. If your change is successful, you will need to merge the change from staging branch to production. Create another PR, this time with the base set to prod and the head set to staging. This PR will trigger a similar Travis process. Test your change on production for good measure.