TA Support for Building and Testing Custom Course Containers on DSMLP
This document describes how to test and maintain custom Docker images for courses on the Data Science/Machine Learning Platform (DSMLP). Information about standard DSMLP Docker images is also available.
For more information about DSMLP, see the FAQ.
Please see https://github.com/ucsd-ets/datahub-example-notebook/blob/master/additional-information.md for Dockerfile best practices
To have a custom Docker image on DSMLP, you'll have to request it when submitting an Instructional Technology Request (CINFO; cinfo.ucsd.edu) for your course. If you already submitted your request, update the support.ucsd.edu Service Now (SNOW) ticket that the CINFO request automatically created with the specifics. Please include the following:
The DSMLP team will configure a GitHub repository with a Dockerfile and a build process for automatically updating the image upon a git push to the repo. We typically create git branches to correspond to specific Docker tags. For example, pushing changes to the
wi23 branch on Github will update the
New base images are released from time to time. To update use a new base image, update the FROM line of the Dockerfile. For example, to change from the Spring 2023 image (2023.2-stable) to the Fall 2023 image (2023.4-stable) you would change the FROM line to the Dockerfile to:
A new version of the image is built and tagged each time the git repository is updated. The tag is the name of the branch, e.g. main, The previous tag main is overwritten.
To preserve a version of an image you can create a tag. For example, you can create a tag named "fa23" for the version of the image used in fall 2023. You can then request that the course uses the "fa23" tag.
test, anything that indicates it's in a test phase. See this document for managing branches: https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/making-changes-in-a-branch/managing-branches
test branch, the build process will kick off. It will eventually publish your new image to your GitHub repository's "Packages" section.
Note: If step 3 didn't complete–i.e., the image didn't build–look through the build logs (located under the “Actions” tab) and investigate why it didn't build correctly. Make the necessary changes and commit your changes to the branch to start a new automated build process.
-i image:tag flag with your myimage:tag, the
-P Always flag, and the -W COURSE_ID flag. The -i flag specifies the image, the -P specifies the image pull policy. Always will always pull the image. -W specifies the workspace.
cogs101-notebook:wi23 and I confirmed that
cogs101-notebook:test works, I'll create a pull request to the