-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hub image - using unreleased versions of some jupyterhub packages #1589
Comments
Quick question, what about putting these packages into a |
Yep! |
Super! |
- Removes custom version of jupyterhub installed, as that has been merged into latest z2jh - We keep the version of oauthenticator, as I'm not sure it has been merged and released Ref 2i2c-org#1055 Ref 2i2c-org#1102 Ref 2i2c-org#1589
- Removes custom version of jupyterhub installed, as that has been merged into latest z2jh - We keep the version of oauthenticator, as I'm not sure it has been merged and released Ref 2i2c-org#1055 Ref 2i2c-org#1102 Ref 2i2c-org#1589
With #1690 we no longer use a custom jupyterhub version! |
That's awesome ✨ So the only pkgs we're using custom versions for, are the |
btw, |
Context
The 2i2c hubs run a custom docker image as per the Dockerfile at https://github.com/2i2c-org/infrastructure/blob/master/helm-charts/images/hub/Dockerfile. More details about this image and how to update it, can be found in the docs at https://infrastructure.2i2c.org/en/latest/topic/hub-image.html.
In this custom hub image we're currently installing unreleased versions of
oathenticator
andconfigurator
. This is because we want to try out the latest changes of this packages and improve/fix anything that might not work as it should.This however means that we're using unreleased versions of these packages and we should make sure we're upgrading to released versions as soon as those are available.
Proposal
A few points about the current situation:
dependabot
andbump-image-tags
action) won't work on the pip packages in thisDockerfile
Starting from the current situation described above, how about instead of always opening new issues about going back to an official released version of a package whenever we pin to a specific commit (as in #1583 (comment)), we document this as being a best practice to follow?
Updates and actions
My suggested plan is to:
The text was updated successfully, but these errors were encountered: