RFD - Setup jupyter-releaser for jupyterlab extensions

[krassowski]

Status	Draft 🚧 / Open for comments 💬
Author(s)	@krassowski
Date Created	2024-10-29
Date Last updated
Decision deadline	2024-11-12

Title

Setup jupyter-releaser for jupyterlab extensions

Summary

• It is beneficial to have multiple extensions doing each one job well (following Unix philosophy):
  • each extension can be disabled or remove separately as needed depending on deployment/development constraints
  • the cost of upgrading to new versions of jupyterlab/extension-template is minimal for each repo thanks to upgrade scripts provided
  • however, releasing each extension could be a cumbersome task without automation
• Releasing and publishing jupyter extensions can be automated by using jupyter-releaser
  • blog post: https://blog.jupyter.org/automate-your-releases-with-the-jupyter-releaser-701e7b9841e6
  • documentation: https://jupyter-releaser.readthedocs.io/en/latest/
  • repo: https://github.com/jupyter-server/jupyter_releaser
• Extensions created from jupyterlab/extension-template are preconfigured to support jupyter-releaser

User benefit

Every admin and every contributor added to release team would be able to release a new version of jupyterlab extensions developed in nebari with approximately 8 clicks.

Design Proposal

There are two ways to use jupyter-releaser:

1. from a GitHub action in the target repository (documentation)
2. from a GitHub action in the fork of the releaser repository (documentation)

I propose to use the (1) approach as this is better for collaboration and needs setting up only once.

There are some workflow assumptions in jupyter-releaser and configuration requirements:

• jupyter-releaser can publish to PyPI and npm signing the artifacts and for PyPI also uses the trusted publishers mechanism; it also allows to lock down the release environment (e.g. by requiring review from another admin or adding a time delay); this requires creation of a GitHub App on the organization and setting up relevant secrets.
• jupyter-releaser can auto-generate neat changelog entries; for that each PR needs to be labelled with a set of pre-defined labels:
  • "bug" (for a bug-fix)
  • "enhancement" (improvement to existing functionality)
  • "feature" (new feature)
  • "maintenance"
  • "documentation"

The following repositories would be using the jupyter-releaser workflow:

• https://github.com/nebari-dev/jupyterlab-jhub-apps
• https://github.com/nebari-dev/jupyterlab-gallery
• https://github.com/nebari-dev/jupyterlab-launchpad
• https://github.com/nebari-dev/jupyterlab-nebari-mode
• maybe https://github.com/nebari-dev/argo-jupyter-scheduler

Alternatives or approaches considered (if any)

• Continue releasing manually
• Setup a custom automation, for example with dispatch on publishing a release on GitHub

Best practices

The labels are in conflict with the currently used labels in nebari-dev; we can investigate configure it in jupyter-releaser to support the labels available in nebari-dev.

User impact

None

Unresolved questions

I will need help setting up the GitHub App and ideally access to a vault where I could put secrets to set it all up.

[viniciusdc]

I support this change