-
Notifications
You must be signed in to change notification settings - Fork 2
Description
| 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
- 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:
- from a GitHub action in the target repository (documentation)
- 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.