Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add
action-typeInput and Kernel Create/Update Modes to Deploy Course ActionFeature Description
Restructure the
action.yamlinputs so thatmode(create/update) applies independently to both articles and kernels. A newaction-typeinput (article/kernel) selects what is being operated on. The existingarticle-type(course/blog) continues to work exactly as before within thearticleaction type.The resulting input matrix is:
Updated
action.yamlNew Scripts (
src/scripts/)The kernel path adds two scripts for
createvsupdate— mirroring the existingcreate_course.py/update_course.pysplit.register_kernelspec.py— kernelcreateFirst-time registration. Generates a new kernelspec directory on the EG host, pre-pulls the image, and restarts EG so the new kernel is immediately discoverable.
patch_kernelspec.py— kernelupdateUpdates an existing kernel without a full re-registration. Patches only the
image_namefield in the existingkernel.jsonon the EG host, then pre-pulls the new image. No EG restart required — the next kernel start will use the new image automatically.Example Workflows (
examples/)Existing —
workflow.yml(unchanged, shown for reference)New —
kernel-create.ymlNew —
kernel-update.ymlAlternatives Considered
Keep a single
modeinput and use values likekernel-create/kernel-update— rejected. Combining two concepts into one string makes the input harder to document and breaks the existingcreate/updatemental model that users already know from the article workflow.Separate
action.yamlfiles for article and kernel — rejected. Two actions would duplicate the shared setup steps (UV install, Python, secret validation, notifications) and require users to maintain two action references in their repos.Implicit detection — infer
action-typefrom which inputs are present — rejected. Explicit is better than implicit for CI configuration. A missingaction-typedefaulting toarticlepreserves backward compatibility without any guesswork.Additional Context
Backward compatibility is fully preserved.
action-typedefaults toarticle, so every existing workflow that omits it continues to work without any changes.mode: updatefor kernels does not restart EG. Running kernel sessions are unaffected — they hold a reference to the container that was started with the previous image. Only new sessions started after the update will use the new image. This is intentional and matches how EG manages container lifecycle.kernel-display-namemust exactly matchkernelIdincourse.jsonanddisplay_nameinkernel.jsonon the EG host. This is the string qBook sends to EG when a student opens a notebook.Related resources
- Existing
- Jupyter Enterprise Gateway docs
- gateway_provisioners
- google-github-actions/auth
- TESTING.md
# Add `action-type` Input and Kernel Create/Update Modes to Deploy Course Actionexamples/workflow.ymlFeature Description
Restructure the
action.yamlinputs so thatmode(create/update) applies independently to both articles and kernels. A newaction-typeinput (article/kernel) selects what is being operated on. The existingarticle-type(course/blog) continues to work exactly as before within thearticleaction type.The resulting input matrix is:
action-typemodearticle-typearticlecreatecoursearticleupdatecoursearticlecreateblogarticleupdateblogkernelcreatekernelupdateNo existing workflow files break.
action-typedefaults toarticleso all current usage continues without any changes.Motivation
The current
modeinput conflates two independent concerns — what is being deployed (an article or a kernel) and how it is being deployed (creating for the first time or updating). Addingaction-typecleanly separates these:mode: createvsmode: updatefor courses. The same mental model should apply to kernels — create a kernel for the first time, or update an existing one with a new image.article-type: course/blogunderaction-type: articlemeans zero changes for existing users.createvsupdatedistinction because the two operations are meaningfully different:createregisters a brand-new kernelspec directory on the EG host, whileupdateonly patches theimage_namein an existingkernel.jsonand pushes a new image tag — no EG restart needed for an update.Proposed Solution
Input structure
Step execution matrix
createvsupdatefor kernelsmode: createmode: update:latest:latestjupyter-docker-spec installimage_namein existingkernel.jsononlyOutputs — separated by
action-typeOutputs are written by a dedicated
emit-outputsstep that only fires for the matchingaction-type. This keeps article and kernel outputs strictly isolated — consumers never need to inspectaction-typeto know which outputs are valid.Article outputs (only populated when
action-type: article):course_namecourse-custom-idqbook_urlKernel outputs (only populated when
action-type: kernel):kernel-namekernel-display-namekernel-imageUpdated
action.yamlNew Scripts (
src/scripts/)The kernel path adds two scripts for
createvsupdate— mirroring the existingcreate_course.py/update_course.pysplit.register_kernelspec.py— kernelcreateFirst-time registration. Generates a new kernelspec directory on the EG host, pre-pulls the image, and restarts EG so the new kernel is immediately discoverable.
patch_kernelspec.py— kernelupdateUpdates an existing kernel without a full re-registration. Patches only the
image_namefield in the existingkernel.jsonon the EG host, then pre-pulls the new image. No EG restart required — the next kernel start will use the new image automatically.Example Workflows (
examples/)Existing —
workflow.yml(unchanged, shown for reference)New —
kernel-create.ymlNew —
kernel-update.ymlAlternatives Considered
Keep a single
modeinput and use values likekernel-create/kernel-update— rejected. Combining two concepts into one string makes the input harder to document and breaks the existingcreate/updatemental model that users already know from the article workflow.Separate
action.yamlfiles for article and kernel — rejected. Two actions would duplicate the shared setup steps (UV install, Python, secret validation, notifications) and require users to maintain two action references in their repos.Implicit detection — infer
action-typefrom which inputs are present — rejected. Explicit is better than implicit for CI configuration. A missingaction-typedefaulting toarticlepreserves backward compatibility without any guesswork.Additional Context
Backward compatibility is fully preserved.
action-typedefaults toarticle, so every existing workflow that omits it continues to work without any changes.mode: updatefor kernels does not restart EG. Running kernel sessions are unaffected — they hold a reference to the container that was started with the previous image. Only new sessions started after the update will use the new image. This is intentional and matches how EG manages container lifecycle.kernel-display-namemust exactly matchkernelIdincourse.jsonanddisplay_nameinkernel.jsonon the EG host. This is the string qBook sends to EG when a student opens a notebook.Related resources
examples/workflow.yml