Last week, Yuvi Panda spent the week here at eScience. This was an opportunity to overhaul the way in which the learning-2-learn Jupyterhub is deployed and the way in which work is distributed in this hub. Until now, deployment was done “by hand”: every time an update had to be done, I would edit the relevant configuration file (e.g., the Dockerfile containing the specification of the computational environment, or the yaml files setting the jupyterhub configuration) and then deploy an update. To automate this process, Yuvi has developed hubploy. In conjunction with Github Actions, an edit to files in a repository can now be used to automatically deploy a change to configuration on a staging hub, where these changes can be tested, without affecting the work of hub users. Then, after verifying that the changes are the ones you want, another push and Github Actions run updates the prod deployment of the hub. This configuration (our example here) should increase robustness, and also allow others to suggest changes to the deployment, by editing the relevant configuration files and making a pull request.

The process of setting this up still required quite a bit of hand-holding on Yuvi’s part, but the hope is that this is something that will be as easy to do as using the zero to jupyterhub currently is.