Currently - what I had nathan do was create a new branch on our base image repo, modify the dockerfile and push that up. I think it's a bit clunky to have as our normal process.
One idea is to make a cookiecutter repo for the base image which users can clone. It will be pre-baked with the ci config and a template dockerfile and they can push up this repo to our gitlab and it should be able to trigger etc.
Part 2: We build image with this Dockerfile
CI file in user upload will trigger build. Need to make sure this triggers the downstream for "jupyter_image" build as well.
Something that also needs to happen here is once their base image builds, we need to add it to the list of base images in the txt file in the jupyter_image repo. When the build is triggered from changes on the github maap-jupyter-ide side, this is where it gets the base images to build off of.
Part 3: Automatic stack/dev file/something creation
TBD - will change with Che 7. Currently no way to create stack outside of UI
Questions
Do we want to maintain the same tag system for user uploaded images? :stable :2.3 :2.4 - Do we only keep the users latest as :stable?
How do we let users know there is a new version and they should update?
Do we share w everyone? Or just the user that created it?
How do we include description of what their packages are - right now include as part of cookie cutter - in the future can use in the dev file.
gchang
commented
4 years ago
Part 1: User uploads Dockerfile
Part 2: We build image with this Dockerfile
Part 3: Automatic stack/dev file/something creation
Questions