Skip to content
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

Include a reference to the source repository inside the image #86

Open
choldgraf opened this issue Mar 14, 2022 · 3 comments
Open

Include a reference to the source repository inside the image #86

choldgraf opened this issue Mar 14, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@choldgraf
Copy link
Member

choldgraf commented Mar 14, 2022

Context on the use-case
Currently, there's no "quick" way to ask "where is the repository that defined the current user image" for images built from this action. This would be very useful for debugging or understanding the user environment for a JupyterHub.

Describe the solution you'd like
To be able to list the location of the image's source files from within the user image. For example, either:

  • A menu-dropdown in JupyterLab or an entry in the JupyterHub admin page that would have a link like: Link to user image repository.
  • An environment variable I could grab like os.environ["USER_IMAGE_SOURCE"]

This would make it much quicker to figure out where source image files are located, which would make it faster / simpler to debug.

Implementation ideas

Binder already does something like this, and it is very useful. For example, in the classic notebook interface:

image

and in lab:

image

(I'm not sure where this is implemented though)

@choldgraf choldgraf added the enhancement New feature or request label Mar 14, 2022
yuvipanda added a commit to yuvipanda/repo2docker that referenced this issue Mar 15, 2022
Until now, 'appendix' was ignored for repos built with
their own Dockerfile. This fixes that, and sets the appendix
on repos built with Dockerfiles too.

I want to set a REPO_URL env var for all images built with
repo2docker-action
(jupyterhub/repo2docker-action#86)
and this is needed for that.
yuvipanda added a commit to yuvipanda/repo2docker that referenced this issue Mar 15, 2022
Until now, 'appendix' was ignored for repos built with
their own Dockerfile. This fixes that, and sets the appendix
on repos built with Dockerfiles too.

I want to set a REPO_URL env var for all images built with
repo2docker-action
(jupyterhub/repo2docker-action#86)
and this is needed for that.
@manics
Copy link
Member

manics commented Mar 16, 2022

(I'm not sure where this is implemented though)

It's https://github.com/manics/jupyter-offlinenotebook. I've been meaning to transfer it to the JupyterHub GitHub org, was hoping to clean up some dependabot things first but maybe I should worry about that later.

@manics
Copy link
Member

manics commented Mar 16, 2022

Can we add this metadata in a more structured way, for example by using container labels (some standard ones are in https://github.com/opencontainers/image-spec/blob/main/annotations.md but we can add more), and then perhaps expose them as environment variables when running the image? This means repo2docker or BinderHub would have to

  • query the built image for all labels
  • Add them to the environment (all, or perhaps just a subset, e.g. rees.*), so LABEL rees.image.source.repo=https://github.com/jupyterhub/example gets mapped to environment variable REES_IMAGE_SOURCE_REPO when the container is run?

The key difference from jupyterhub/repo2docker#1144 is that we'd make this part of repo2docker/binderhub and always set the required environment variables using the standard container run API instead of relying on Appendix to be configured by a user.

@choldgraf
Copy link
Member Author

@manics definitely +1 on doing this in a more structured way! Environment variables seems reasonable to me. Then it would be up to extensions, UIs, etc to use those variables and expose them to users in whatever way they wanted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants