2i2c-org / hub-user-image-template Goto Github PK

Description

This repository focuses on a more straightforward environment where people need a "vanilla" repo2docker setup in order to get the image running. This is super useful for most communities, though I think that there's an "advanced use-case" that we should cover as well, which is rolling your own Dockerfile.

The most obvious use-case that this enables is when you want to start with a different base image, which is not currently possible with repo2docker.

Benefit

There are many communities that want to use other images as a base, since a lot of communities maintain base images that are meant to help with reproducibility. One non-python example is the rocker project in the R community.

Implementation

As @sgibson91 noted, a good reference to use for inspiration would be the COESSING image repository, which does some more complex setup.

Another thing we should consider is that we might extend this repository to use more complex build files. For example, if people wanted an example using a postBuild script to configure the Jupyter server. I think the question boils down to "how many use-cases require the use of a Dockerfile (like using a different base image) vs. how many can we just show off more complex repo2docker setups w/o a Dockerfile.

Tasks

• Understand what other use-cases are best-suited to a Dockerfile
• Decide whether they make sense to include in this repository, vs. splitting into a separate template repository

In a presentation by @yuvipanda, two types of image needs are considered:

• one where an image is built based on high-level files like environment.yml using repo2docker
• one where an image is built with a plain Dockerfile (build with or without repo2docker)

I think there is a need for this template repo to clarify that repo2docker will respect a Dockerfile if its found, and build it without doing something fancy with high-level files. Further, that this is a reasonable use of this template if for example you want to add a single package like done in https://github.com/2i2c-org/scipy-notebook-with-nbgitpuller/blob/main/Dockerfile by adding a Dockerfile.

Background

I am hearing from researchers at LEAP that they have trouble building images locally.

I realize this can be hard on a variety of machines (windows seems to cause trouble), so here is a suggestion:

Can we provide a docker image with docker, repo2docker, etc that we could run on a 2i2c hub, so that user can create and test their repo before pushing to github (and thus creating a potentially big image in the registry via the CI)?

Happy to help with testing this

Context

I suspect the pins for the below are incorrect for latest repo2docker based images, this template should be updated - possibly as part of the image management work if it is going to continue to be the base for community images

  - jupyter_contrib_nbextensions==0.5.1
  # Required until https://github.com/jupyterhub/repo2docker/pull/1196 is merged
  - jupyterhub-singleuser>=3.0,<4.0

Proposal

No response

Updates and actions

No response

A researcher at LEAP just noticed that the link in the readme https://docs.2i2c.org/en/latest/admin/howto/environment/hub-user-image-template-guide.html is not working anymore. Does anyone here know what the correct replacement is?

Context

The links to the following bullet points in the README file don't work.

• How to create and use a custom user image for your hub
  • Use this template
  • Hook the new repository to quay.io
  • Enable image push to quay.io
  • Enable quay.io image push for build.yaml
  • Enable quay.io image push for test.yaml
  • Customize the image
  • Build and push the image
  • Connect the hub with this user image
  • Test the new image
• Push image to a registry other than Quay.io

Also the links within Overall workflow

Proposal

I'd suggest to remove or comment them if the documentation is WIP.

Updates and actions

No response

Background and proposal

Context
A common workflow for this action is:

1. Edit an environment file
2. Merge into main
3. Wait for the action to build the image to complete
4. Look at its logs to figure out the SHA for the new image (and its location)

Users are probably looking for the information in step 4, but it's a bit hard to find for people who don't know where to look. For example, you need to know to look for the "Update jupyter dependencies with repo2docker" section, and look to the bottom for the SHA. But what if somebody is using RStudio and not Jupyter? What if somebody doesn't realize that this is not only updating the dependencies but also pushing a new image? They may not know to click there.

Proposed solution

I think that we should add a final step to our action called something like "Print important information about new image".
This would print all of the necessary information a person might want in order to update their image. For example, the location of the registry, the new image tag, a single copy/pasteable string to put into the Configurator, etc.

Implementation guide and constraints

Ideally this is something that we could put into the repo2docker action, but I'm not sure how feasible that is. I think we want these logs to be as easy to find as possible, and if they're embedded as a part of the repo2docker action logs it might be hard to find nonetheless.

An even cooler option (if it's possible) would be to do something similar to the "Test this on Binder" action, and have it post a comment to a PR like:

Finished building user image 🎉
If you merge this PR, the image will be here: `<URL to image on registry>`
The image name and tag will be: `<image-name>:<hash>`

Updates and ongoing work

No response

Context

This is a template repo that many of our communities use to self-serve images for their hubs. We often make changes and improvements to this template, e.g., #10. But it's not clear to me how we push those improvements to the repositories already using this template.

Since this is a template repo, not a fork, trying to pull changes from this repo into a downstream repo in the "usual" way (say, by adding this repo as a template and running git fetch --all && git merge...) will result in a trying to merge unrelated commit histories error.

Proposal

No response

Updates and actions

No response

Description

We should add a GitHub action to this template that automatically provides a "test on Binder" comment to new Pull Requests.

Benefit

This would allow others to quickly test out images to make sure things are updated as expected (and, to make sure that an environment actually builds!)

Implementation

The peddie image has a good example of this workflow in action: https://github.com/2i2c-org/peddie-image/blob/main/.github/workflows/binder.yaml

(Originally posted in 2i2c-org/infrastructure#493 (comment))

We have pins to the patch version in our environment.yml file, and when users clone that and make changes, I think that sets a bad precedence for them.

I've maintained docker images for several years, and having things pinned and not pinned has pro's and con's, but I'm a firm believer that we and people cloning this repo will end up benefiting from not pinning dependencies overall.

Action point

Indicate disagreement or agreement to take the action of unpinning the following dependencies entirely

• jupyter_contrib_nbextensions==0.5.1
• jupyterhub-singleuser>=3.0,<4.0
• nbgitpuller=1.1.*