Some major changes that weren't mentioned in the miro board:
Refactored remote desktop to install mamba on the first layer. This enables future layers to run mamba commands without error
Added clean-layer.sh calls to conda/npm RUN ... commands to reduce layer size, Not that we do use --force-rm in our docker build command, which forces the removal of intermediate build layers.
Added an intial_condarc file to allow the configuration of conda channels during build-time instead of explicity referencing the conda channels in each RUN mamba install ... command -> This might need to be cleaned up in a post-build script
Jupyterlab now shows v4.0.7 instead of 3.6.5 which is great
[x] Does the image pass CI successfully (build, pass vulnerability scan, and pass automated test suite)?
[x] If new features are added that require in-cluster testing (e.g. a new feature that needs to interact with kubernetes), have you added the auto-deploy tag to the PR before pushing in order to build and push the image to ACR so you can test it in cluster as a custom image?
JupyterLab extensions
[ ] Are all extensions "enabled" (jupyter labextension list from inside the notebook)? No
(base) jovyan@test-cpu-0:~$ jupyter labextension list
Config option `kernel_spec_manager_class` not recognized by `ListLabExtensionsApp`.
[W 2023-10-30 13:14:45.610 LabApp] Config option `kernel_spec_manager_class` not recognized by `LabApp`.
JupyterLab v4.0.7
/opt/conda/share/jupyter/labextensions
jupyterlab_pygments v0.2.2 enabled X (python, jupyterlab_pygments)
jupyterlab-execute-time v3.0.1 enabled OK (python, jupyterlab_execute_time)
jupyterlab-plotly v5.18.0 enabled X
nbdime-jupyterlab v2.2.0 enabled X
jupyter-matplotlib v0.11.3 enabled OK
@jupyter-lsp/jupyterlab-lsp v5.0.0 enabled OK (python, jupyterlab-lsp)
@jupyterhub/jupyter-server-proxy v4.0.0 enabled X
@jupyterlab/git v0.41.0 enabled X (python, jupyterlab-git)
@jupyter-widgets/jupyterlab-manager v5.0.8 enabled OK (python, jupyterlab_widgets)
The following extensions are outdated:
jupyterlab_pygments
jupyterlab-plotly
nbdime-jupyterlab
@jupyterhub/jupyter-server-proxy
@jupyterlab/git
Consider checking if an update is available for these packages.
Other labextensions (built into JupyterLab)
app dir: /opt/conda/share/jupyter/lab
jupyterlab-dash v0.4.2 enabled X
The following extensions are outdated:
jupyterlab-dash
Consider checking if an update is available for these packages.
Disabled extensions:
@jupyterlab/completer-extension:base-service
@jupyterlab/fileeditor-extension:language-server
@jupyterlab/lsp-extension:settings
@jupyterlab/notebook-extension:language-server
VS Code tests
[x] Does VS Code open?
[x] Can you install extensions?
Code review
[x] Have you added the auto-deploy tag to your PR before your most recent push to this repo? This causes CI to build the image and push to our ACR, letting reviewers access the built image without having to create it themselves
[x] Have you chosen a reviewer, attached them as a reviewer to this PR, and messaged them with the SHA-pinned image name for the final image to test on the dev cluster (e.g. k8scc01covidacrdev.azurecr.io/jupyterlab-cpu:746d058e2f37e004da5ca483d121bfb9e0545f2b)?
Description
Extensive clean up of the Jupyterlab Images. The remote desktop image was also impacted due to shared dockerbits.
!!!- ALL IMAGES TO BE THOROUGHLY TESTED PRE-MERGE -!!!
ChangeLog
Most of the changes are logged here https://miro.com/app/board/uXjVMj1Jmm4=/
Some major changes that weren't mentioned in the miro board:
mambacommands without errorRUN ...commands to reduce layer size, Not that we do use--force-rmin our docker build command, which forces the removal of intermediate build layers.intial_condarcfile to allow the configuration of conda channels during build-time instead of explicity referencing the conda channels in eachRUN mamba install ...command -> This might need to be cleaned up in a post-build scriptTests / Quality Checks
SHA: 5bc70e4ac4c6c42d65927453a08974de4d046650
-tested cpu, pytorch(cpu), tensorflow(cpu), remote-desktop
Automated Testing/build and deployment
auto-deploytag to the PR before pushing in order to build and push the image to ACR so you can test it in cluster as a custom image?JupyterLab extensions
jupyter labextension listfrom inside the notebook)? NoVS Code tests
Code review
auto-deploytag to your PR before your most recent push to this repo? This causes CI to build the image and push to our ACR, letting reviewers access the built image without having to create it themselvesk8scc01covidacrdev.azurecr.io/jupyterlab-cpu:746d058e2f37e004da5ca483d121bfb9e0545f2b)?