Elyra release

Before you begin

Elyra depends on a few different packages that are under the control of the Elyra community and used mostly to abstract integration with other runtimes and components.

Currently, these packages are:

Before you begin creating a new Elyra release, verify if there is a need to release any of these packages, and if necessary, update Elyra to use the new release.

Elyra release process overview

Building an Elyra release consists of the following steps:

Updating the changelog.md with the list of changes added to the release
Building the Elyra python package.
Building Elyra JupyterLab extensions as npm packages.
Generate and build the modified packages to enable single-extension deployment.
Build and publish multiple docker images

Most of the steps required to prepare and publish a release have been automated through the create-release.sh script, which exposes three goals:

The prepare-changelog goal traverse the recent commits to update the changelog.md for a given release.

create release prepare-changelog --version 2.3.0

The prepare goal create the release artifacts and make them available locally for validation.

create release prepare --version 2.3.0 --dev-version 2.4.0

— The ‘publish’ goal get a previous prepared release and publish the artifacts to respective repositories.

create release publish --version 2.3.0

Creating minor/patch releases from branches

In the case of creating minor/patch releases from a branch, one will need to modify the release script so that it perform a checkout of the given branch after cloning the Elyra repository:

Update the checkout_code function in the create-release script and add the following at the end of that function:

check_run(['git', 'checkout', '<BRANCH NAME>'], cwd=config.source_dir)
check_run(['git', 'status'], cwd=config.source_dir)

Preparing Elyra release

Generate the release changelog

create release prepare-changelog --version 2.3.0

The updated changelog will then be available at ./build/release/elyra as a git commit
- The release manager should make any necessary adjustments and/or updates before ‘pushing the changelog commit’.
- Note that the release manage could also push the change log as a new pull request to gather inputs from the community.

Prepare the release artifacts

create-release.py prepare --version 2.0.0 --dev-version 2.1.0 [--rc 0][--beta 0]

The artifacts for the new release will then be available at ./build/release/
- The Elyra folder is the main release
- The other folders, are the individual extensions packaged as standalone packages

elyra
elyra-code-snippet-extension
elyra-pipeline-editor-extension
elyra-python-editor-extension
elyra-r-editor-extension

Test the release
- Run multiple scenarios, to make sure each extension is working ok
- Run the covid-notebook scenario
- Run the NOAA sample

Publish the release

create-release.py publish --version 2.0.0 [--rc 0] [--beta 0]

Build and publish container images based on release tag

git pull --rebase
git checkout tags/v2.0.0
make container-images publish-container-images

Update dev and latest image tags based on release tag

docker tag elyra/elyra:2.0.0 elyra/elyra:dev && docker push elyra/elyra:dev
docker tag elyra/elyra:2.0.0 elyra/elyra:latest && docker push elyra/elyra:latest
docker tag quay.io/elyra/elyra:2.0.0 quay.io/elyra/elyra:dev && docker push quay.io/elyra/elyra:dev
docker tag quay.io/elyra/elyra:2.0.0 quay.io/elyra/elyra:latest && docker push quay.io/elyra/elyra:latest

docker tag elyra/airflow:2.0.0 elyra/airflow:dev && docker push elyra/airflow:dev
docker tag elyra/airflow:2.0.0 elyra/airflow:latest && docker push elyra/airflow:latest
docker tag quay.io/elyra/airflow:2.0.0 quay.io/elyra/airflow:dev && docker push quay.io/elyra/airflow:dev
docker tag quay.io/elyra/airflow:2.0.0 quay.io/elyra/airflow:latest && docker push quay.io/elyra/airflow:latest

Merge changes for conda-forge

Developer guide: Elyra documentation

Release history