Replace Travis with GitHub workflow

[manics]

publish workflow is untested
The tests are hanging on K3S 1.17.3 and 1.16.15, but passing for 1.18.10 and 1.19.3 Seems to be an ipv6 problem with older K3s versions.

Closes #1872

[consideRatio]

Wieeee thank you for your work on this @manics! Really looking forward to be able to exclude triggering builds when there is no point to them by selecting paths to watch for changes.

# Only run this when the master branch changes
on:
  push:
    branches:
    - master
    # If your git repository has the Jupyter Book within some-subfolder next to
    # unrelated files, you can make this run only if a file within that specific
    # folder has been modified.
    #
    # paths:
    # - some-subfolder/**

I'm putting in a lot of work on jupyterhub/binderhub and hope that work can us help us transition to using this tooling in the long run.

[manics]

I think this is ready! I had to add a delay in bcff6bf. A run was failing around 10% of the time, since there are 5 runs this means a failure ~50% of the time. Adding a delay seems to give all K8s resources time to stabilise.

Note I haven't tested the publish workflow.

This uses manics/action-k3s-helm@v0.2.1, should I transfer it to the jupyterhub GitHub org or leave it under my account?

[consideRatio]

Thank you @manics for your work on this! I know from experience this kind of work can take quite a bit of time! ❤️ 🎉

I made some change requests, let me know if you want help to get this PR all the way!

• Update CONTRIBUTING.md following the changes
• Give the publishing script a pass by creating a new private SSH deployment key to inject in this repo in the publishing job
• Configure DOCKERHUB_USERNAME and DOCKERHUB_PASSWORD secrets to be available

[consideRatio]

There are environment variables used to decrypt an encrypted SSH key registered with the jupyterhub/helm-chart repo so we can push to it. We have to either replace that SSH key with a new one we have encrypted or create a new deploy key for jupyterhub/helm-chart, encrypt it, and use an environment variable as key to decrypt it.

Let's create a new SSH public/private key, encrypt the private in this repo using some secret, and register the public part for push access in the jupyterhub/helm-chart repo here: https://github.com/jupyterhub/helm-chart/settings/keys.

Or, perhaps there is a GitHub action way to help us get a SSH key encrypted into the repo? Ah yes! Let's try out this action perhaps? https://github.com/marketplace/actions/install-ssh-key

[consideRatio]

I added a commit and registered a deployment key etc, but credentials for dockerhub remain still. I have asked @minrk for help about this.

@minrk I'd like to provide GitHub actions the password for the dockerhub jupyterhubbot account in order to let pushes for z2jh work. This will probably also be done for binderhub in the end, could you provide me with the password or add DOCKER_USERNAME and DOCKER_PASSWORD here:

https://github.com/jupyterhub/zero-to-jupyterhub-k8s/settings/secrets/actions
https://github.com/jupyterhub/binderhub/settings/secrets/actions

[betatim]

@manics how do the tests that run outside the k8s cluster figure out what the IP is on which they can reach the JupyterHub API? It looks like proxy-public is deployed as a "NodePort" type service with a fixed port. If this was minikube I'd expect something like minikube ip in order to find the IP to go with the port. However I can't find the equivalent for k3s :-/ I did find that coreDNS was being patched so that local.jovyan.org always resolves to the porxy service, but I think that magic trick only works if you are inside the cluster.

Trying to figure this out while moving BinderHub to GitHub actions.

[consideRatio]

@betatim local.jovyan.org resolves to 127.0.0.1 unless hacked inside the cluster to point to proxy-public svc.

Minikube ip isnt needed with k3s as there is no virtual machine with separate network i think. Hmmm, or not 100% on this really, but i think you are fine in binderhub to not find a custom ip, or hmmm?

Well oh there is also the crux of minikube needing to separate a public and private ip, i merged @manics pr adding that traitlet, hub_url_local.

[betatim]

Ah yes. I'm still too much in my OSX world where you can't run kubernets "on the host", instead you are always inside a VM (k3d, minikube, minishift, etc). The answer is that http://localhost:<NodePortPort>/hub/api is where you can reach a service inside the k3s cluster.

[manics]

I'm a bit short on time at the moment, I can see you've already pushed to this branch, feel free to continue doing so 😄

[consideRatio]

We still haven't DOCKER_USERNAME and DOCKER_PASSWORD configured, so the publish job will fail on merge, but let's go with this for now until we get help from Min with this.

[consideRatio]

@manics thank you so much for your work on this! The extraction of the k8s cluster setup step into a dedicated part is very appreciated apart from the big help with transitioning to GitHub actions from Travis CI. 🎉 ❤️

I'll go ahead and merge this now to enable our test suite to function again!

[consideRatio]

@manics everything seem to work and I managed to get rid of the 1m delay in #1896! 🎉