jupyter-server / jupyter_releaser

A set of helper scripts and GitHub Actions to aid in automated releases of Python and npm packages.

Jupyter Releaser

Jupyter Releaser contains a set of helper scripts and GitHub Actions to aid in automated releases of Python and npm packages.

Installation

To install the latest release locally, make sure you have pip installed and run:

    pip install git+https://github.com/jupyter-server/jupyter_releaser

Library Usage

    jupyter-releaser --help
    jupyter-releaser build-python --help
    jupyter-releaser check-npm --help

Checklist for Adoption

See the adoption guides.

Actions

GitHub actions scripts are available to draft a changelog, draft a release, publish a release, and check a release.

See the action details documentation for more information.

The actions can be run on a fork of jupyter_releaser and target multiple repositories, or run as workflows on the source repositories, using shared credentials.

jupyter_releaser's Issues

Skip the check_manifest check if there is not MANIFEST.in fiile

Problem

Other backends do not use this file and would have to manually skip this check.

Proposed Solution

Check for the existence of a MANIFEST.in file, and bail with a warning if there is none.

[QUESTION] Is this only for Jupyter related projects?

Hi, On the README, I read Jupyter Releaser contains a set of helper scripts and GitHub Actions to aid in automated releases of Python and npm packages..

From that, I may conclude that any non-jupyter project having python and npm packages could use the jupyter_releaser solution to manage its releases...

Is this correct?
What are the constraints to meet to use jupyter_releaser?

Make twine check strict by default

Problem

We are running twine check, but not handling warnings

Proposed Solution

• Use twine check --strict by default but allow it to be overridden.

Simplified Workflow

Problem

• It is cumbersome to make releases using a separate repository.
• It requires every maintainer to set up their fork and maintain a token map.
• It requires several manual steps.

Proposed Solution

We could have an optional usage that works as follows:

• Maintainer creates a draft release from the GitHub UI - this does not yet create a tag.
  • Use the GitHub-provided release notes and edit as desired.
• Maintainer Runs Publish Draft Release workflow in the Repo.
  • Optionally takes a draft workflow url, otherwise uses the latest.
• The Publish Draft Release workflow will:
  • Bump the version
  • Update the changelog entry to use github-activity formatting (based on a setting)
  • Build the assets
  • Create a tag and pushes it
  • Upload the assets to the GitHub release
  • Publish the assets to npm and/or PyPI
  • Finalize the release
  • Open a forwardport PR if necessary
  • Bump to dev version automatically after the release based on config. I had thought #294 fixed this but it only handles the cases where "next", "patch", and "minor" are used. Here we'll have explicit tags
• Maintainer merges the forwardport changelog PR(s) if applicable.

By using a tag protection rule only users with Maintain and Admin roles would be able to publish.

We already have most of the building blocks to build the new action.

The action should check to see whether the assets are already included, which allows you to re-try if there is a publish failure. If there is a problem with the draft release itself you can delete it and start over.

Check Links fails right after a new release

Problem

When a new release has been published with the commit and tag created on the main branch:

The check release script triggered on a new PR can fail with the following:

Example PR: jtpio/ipylab#76
Example run: https://github.com/jtpio/ipylab/runs/3526255104

Proposed Solution

This seems to be because there is no new change since the last tag when generating the changelog (None).

Maybe the fix could be to default the Full Changelog url to use the latest tag instead of None.

Additional context

`prep-git` step fails if `yarn` is already installed

Description

Trying out the CLI locally, it looks like the jupyter-releaser prep-git command fails if yarn is already installed.

Reproduce

Create a new conda environment with yarn.

Locally, install jupyter-releaser from pip with pip install jupyter-releaser.

Then run jupyter-releaser prep-git.

+ git checkout main
Already on 'main'
Your branch is up to date with 'origin/main'.
+ npm install -g yarn
npm ERR! code EEXIST
npm ERR! path /path/to/env/bin/yarn
npm ERR! EEXIST: file already exists
npm ERR! File exists: /path/to/env/bin/yarn
npm ERR! Remove the existing file and try again, or run npm
npm ERR! with --force to overwrite files recklessly.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/user/.npm/_logs/2021-06-28T13_58_10_269Z-debug.log

Expected behavior

Either it force replaces the existing yarn, or skip the step if yarn is already installed.

Custom get version command

Problem

There is already a version-cmd command option to be able to specify a custom command to bum version.

It would also be useful to be able provide a custom command to retrieve the version. For example when the repo contains multiple Python packages, or when the pyproject.toml / setup.py files are not at the top-level.

Proposed Solution

Similar to version-cmd, we can add a get-version-cmd option to be able to run an arbitrary command to retrieve the version.

Additional context

This came up when trying to adopt the release for jupyterlite: jupyterlite/jupyterlite#319

In this repo, the main CLI (a Python package) is under py/jupyterlite, and there is no top-level setup.py. Later there might also be more Python packages living under py/.

There is however a top-level package.json so the version could already be retrieved from there. But we still want to use the Python version for the changelog and tags.

Better parsing of python package name

We can use pkginfo on the distribution file to get the package info, including the name

Test Against Notebook

Test against https://github.com/jupyter/notebook
Will require jupyter_releaser config to handle jsversion and translations steps.

Document the usage of the new "field" parameter for tbump

As of tbump 6.6.0, we can use the field parameter instead of the wonky way we're currently computing version_info.

We're currently using that pattern in several other repos.

Documentation Label is Always Removed

Description

In #211 I attempted to remove the documentation label when there were no documentation PRs, but it is currently removing the label always.

Config for releasing multiple projects with a fork

Problem

Using the Jupyter Release with multiple projects requires updating the npm and PyPI tokens in the GitHub Secrets.

This may be error-prone due to copy pasting, and maybe a bit tedious when maintaining and releasing several projects.

Proposed Solution

Ideally there could be two extra inputs to the action:

• PyPI token name, for example MYEXTENSION_PYPI_TOKEN
• npm token name: for example MYEXTENSION_NPM_TOKEN

Not sure GitHub Actions allow for dynamic secret lookups though.

Additional context

This came up as an observation after testing with the JupyterLab extension cookiecutter: jupyterlab/extension-cookiecutter-ts#162

Handle multiple Python packages

Problem

At the moment the releaser assumes there is a single Python package located at the root of the repository.

There are several checks in the code base that look for a setup.py or pyproject.toml file. For example:

jupyter_releaser/jupyter_releaser/cli.py

Lines 369 to 371 in 9c9902b

	if not util.PYPROJECT.exists() and not util.SETUP_PY.exists():
	util.log("Skipping build-python since there are no python package files")
	return

However, some repos have multiple Python packages. This is the case for ipywidgets:

• top-level ipywidgets package: https://github.com/jupyter-widgets/ipywidgets/blob/master/setup.cfg
• jupyterlab_widgets (for the JupyterLab extension): https://github.com/jupyter-widgets/ipywidgets/blob/master/jupyterlab_widgets/setup.cfg
• widgetsnbextension (for the classic notebook): https://github.com/jupyter-widgets/ipywidgets/blob/master/widgetsnbextension/setup.cfg

Proposed Solution

For npm packages there is already the concept of workspace packages, and is supported by the releaser.

However this doesn't seem to be standardized for Python monorepos. So maybe we could instead have an option to specify a list of directories pointing to the Python packages?

In the case of ipywidgets it might look like the following:

[tools.jupyter-releaser.options]
python_packages = [".", "jupyterlab_widgets", "widgetsnbextension"]

The releaser would then build each package from the list, and stage the built assets to the dist-dir.

Additional context

jupyter-widgets/ipywidgets#3285

Add ability to use "next" target for tbump-based repos

Problem

Currently you have to keep track of build and patch numbers when making releases.

Proposed Solution

We should be able to parse standard version strings and bump the last number automatically for the user.

More robust get_version()

Problem

We do not yet support dynamic versions that follow PEP 517.
We currently rely on setup.py --version or a static version in pyproject.toml.

Proposed Solution

We can look for a static version in pyproject.toml. If it is dynamic, we use the build backend to run prepare_metadata_for_build_wheel, and then extract the version from the created METADATA file. This gives us a PEP-supported way to get the version info, without having to build the actual wheel.

Check Release Action: Upload release assets as artifacts?

Problem

The Check Release Action is really convenient to validate the repo is compatible with the releaser.

Wondering whether we could also upload the release assets as GitHub Actions artifacts? So they could be downloaded if needed, just to double check. The tarball would contain both the Python and npm packages if available.

Proposed Solution

Extend the check release action to upload built assets as artifacts.

Additional context

Package for conda

Problem

For convenience and for those who want to use jupyter-releaser from the command line directly, it could be useful to have it packaged for conda.

Proposed Solution

We can add a new recipe to: https://github.com/conda-forge/staged-recipes

Using `after-git-prep` in Draft Changelog workflows

We can’t yet use after-git-prep in Draft Changelog workflows because we don’t have the remote repo’s metadata until after the git checkout.  We need to re-read the config before running the after hooks.

New workflow to draft a release and directly publish it

Problem

For small scale projects, we might want to group both the draft and release workflows, dropping the Publish Release step, so there is only one workflow to run.

Proposed Solution

There could be an additional workflow, combining the options from both the draft and release workflows.

The release URL would have to be retrieved from:

jupyter_releaser/jupyter_releaser/lib.py

Line 257 in aefad8b

util.actions_output("release_url", release.html_url)

Additional context

Document the usage of labels

Add documentation about which 5 labels should be used in PRs: bug, maintenance, documentation, enhancement, or feature.

Handling of monorepos

Using the Jupyter Releaser with a monorepo, it looks like the packages are retrieved with glob patterns and might be returning too many results:

Probably the logic is somewhere here:

jupyter_releaser/jupyter_releaser/npm.py

Line 154 in 8285f2d

for path in glob(pattern, recursive=True):

Originally posted by @jtpio in #46 (comment)

The Final Countdown

Everytime we use the Jupyter releaser, I can hear Europe's song "The Final Countdown" play in a loop until the release process is finished. I suggest we add a command line option to make this an opt-in for everyone.

Use New Input Forms

Problem

Some of our options are booleans that are presented as text fields

Proposed Solution

Use the new github.blog/changelog/2021-11-10-github-actions-input-types-for-manual-workflows

Improve Git Clone Performance

Problem

It can be slow to git clone, but we can't do a shallow checkout because we need tags.

Proposed Solution

Use git clone --filter=blob:none, which gets all the tags, but not previous file blobs that are not needed.

Additional context

This option was used in pip to improve performance.

Use Local PyPI Server for Dry Run

• Use https://github.com/pypiserver/pypiserver for dry run uploads
• Twine does not support dry run
• The notebook package already exists on test.pypi.org, and this is a general problem of package squatting on that server.
• This allows us to avoid needing the TEST_PYPI_TOKEN on the target repository

Add support for "minor" version spec

Problem

We have a convenience function ("patch" or "next") for patch releases, but none for minor releases.

Proposed Solution

Add handling of "minor" releases for "tbump".

Additional context

The author of tbump does not want to include the feature upstream.
Here's where we handle "patch" releases

Test Against Jupyter Server

Test this release process against Jupyter Server.

Add a check_release workflow to Jupyter Server, and perform a release of jupyter_server to the test PyPI server. Then we can target the public PyPI server and move this library out of the experimental phase.

Relevant PRs:
jupyter-server/jupyter_server#494
jupyter-server/jupyter_server#498
jupyter-server/jupyter_server#499

Upload `SHA256SUMS` as a GitHub Release asset

Problem

It is often good practice to upload a SHA256SUMS file next to the other release assets for integrity.

Proposed Solution

We can add a step to the releaser to compute these hashes, and upload them when creating the GitHub Release.

Add optional announcement action to post changelog or release to discuss.jupyter.org

Add an optional action to publish the changelog or link to it on Discourse Announcements.

Add Automatic Handling of GitHub Actions Tag

Problem

We are currently using a custom script here and in maintainer-tools to manage GitHub Actions tag.
We also want to be able to quickly roll back a tag if we make an errant release.

Proposed Solution

• Add config for the current GitHub Actions tag, and automatically manage that tag when making a release.
• Add a _prev label to the previous tag location
• Add a workflow to roll back to the _prev tag for the current release given a target repo

Automatically set the label for the changelog PR

Problem

We have to remember to manually add the documentation label on the Automated Changelog PRs, unless the repo is using an auto-labeller.

Proposed Solution

Automatically attempt to add the "documentation" label to the created PR, and fail gracefully if the label is not available.

Branch Should Be Optional

Problem

We should use the default branch if no branch is given in the workflow.

Proposed Solution

We can use the equivalent of git remote show origin | grep 'HEAD branch' | cut -d' ' -f5 to get the default branch if none is given. We can also make version_spec optional given #221, and then in most cases we just need to give a repo as input.

Full Release job failed but the package is correctly published

Description

I just made the voila 0.3.3 release using the Full Release job (using jupyter_release master). The job can be found failing here: https://github.com/martinRenou/jupyter_releaser/actions/runs/1967872160 but the package was correctly published and tag created https://pypi.org/project/voila

@jtpio said

this might be related to jupyter-server/jupyter_releaser#262
there should not have been a forward port PR for the voila release, since it was released from the main branch

Expected behavior

Context

• Operating System and version:
• Browser and version:
• Jupyter Server version:

Troubleshoot Output

Paste the output from running `jupyter troubleshoot` from the command line here.
You may want to sanitize the paths in the output.

Command Line Output

Paste the output from your command line running `jupyter lab` here, use `--debug` if possible.

Browser Output

Paste the output from your browser Javascript console here, if applicable.

RH_VERSION_SPEC env var is ignored in the check release step

Description

Looks like the latest 0.9.x might have lost support for passing RH_VERSION_SPEC as part of check-release environment variable.

Reproduce

This example run on the JupyterLab repo: https://github.com/jupyterlab/jupyterlab/runs/3948255224

With JupyterLab making use of RH_VERSION_SPEC: next here:

https://github.com/jupyterlab/jupyterlab/blob/00613a3f14b3f292f349e60fa12d2ca441ddeeb0/.github/workflows/check-release.yml#L72

Expected behavior

The previous behavior should still be supported.

404 when publishing the package to npm

Description

While testing the Jupyter Releaser with a JupyterLab prebuilt extension (Python + npm), the Publish Release workflow (example run) would fail to upload the tarball to npm:

This package was already available on npm before.

Updating the workflow with the following diff (as mentioned in jupyterlab/extension-cookiecutter-ts#162 (comment)) helped going through:

 .github/actions/publish-release/action.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.github/actions/publish-release/action.yml b/.github/actions/publish-release/action.yml
index 15b4844..517db7e 100644
--- a/.github/actions/publish-release/action.yml
+++ b/.github/actions/publish-release/action.yml
@@ -31,6 +31,8 @@ runs:
         export RH_DRY_RUN=${{ inputs.dry_run }}
         export release_url=${{ inputs.release_url }}
         export RH_NPM_COMMAND="npm publish --access public"
+        
+        echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > ~/.npmrc
 
         # Install Jupyter Releaser from git
         pip install -q git+https://github.com/jupyter-server/jupyter_releaser.git@v1

Reproduce

It should be possible to reproduce by:

• creating a new extension from the cookiecutter
• go through the jupyter releaser process

Expected behavior

The publish workflow should not fail publishing the package.

Context

For more context: jupyterlab/extension-cookiecutter-ts#162

Add documentation for Publish Release

Sometimes when the "Full release" workflow fails because of an expired token, it is easy to change the token and continue by running the "Publish release" workflow. The problem is that the "Publish release" is not documented, or the user doesn't know they can continue the release from there.

Clean up Handling of Dev Versions

Problem

Our current handling of .dev versions is awkward.
It is unclear which version spec to use, and the setting is manual in the Full Release workflow.

Proposed Solution

Get the current version from the changelog instead of the package itself. This allows next, patch, etc. to work from that version.
Instead of post version spec, have a setting for the dev version: None, patch, or minor. It will automatically be applied.

Additional context

This will be needed for #272

'COMMAND could not be found' in the check release workflow

Description

The check release workflow seems to be giving false positives and does not check the release.

Reproduce

Use the latest published check-release workflow of the releaser.

Example workflow: https://github.com/jupyterlab/retrolab/runs/3114328653

Expected behavior

The workflow seems to be bailing early here:

jupyter_releaser/.github/actions/check-release/action.yml

Lines 35 to 40 in 83f7bc0

	# Install Jupyter Releaser from git unless we are testing Releaser itself
	if ! command -v jupyter-releaser &> /dev/null
	then
	echo "COMMAND could not be found"
	exit
	fi

But should proceed with the next steps.

Context

Example workflow: https://github.com/jupyterlab/retrolab/runs/3114328653

check-python does not support package name not being importable

It is possible to set a Python package name that does not match any python packages. This breaks check-python because one of the check is to test for python -c "import <package_name>".

schema.json not found

Description

I recently had the following error:

Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/runpy.py", line 1[97](https://github.com/jupyter-server/jupyverse/runs/5690961585?check_suite_focus=true#step:10:97), in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/jupyter_releaser/actions/draft_changelog.py", line 6, in <module>
    from jupyter_releaser.util import CHECKOUT_NAME
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/jupyter_releaser/util.py", line 45, in <module>
    SCHEMA = files("jupyter_releaser").joinpath("schema.json").read_text()
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/pathlib.py", line 1266, in read_text
    with self.open(mode='r', encoding=encoding, errors=errors) as f:
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/pathlib.py", line 1252, in open
    return io.open(self, mode, buffering, encoding, errors, newline,
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/pathlib.py", line 1120, in _opener
    return self._accessor.open(self, flags, mode)
FileNotFoundError: [Errno 2] No such file or directory: '/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/jupyter_releaser/schema.json'

PRs generated from a fork cannot run check_release

PRs generated from a fork cannot run check_release as of now

• We need to separate the branch parameter into ref (the source reference) and target (the target branch) since the branch does not exist on the target repo.
• We cannot make draft GitHub releases because we have a read-only token. Technically we can run the workflow on the forked repository but it would not be visible to a reviewer of a pull request.
• So, check_release needs to be modified to build assets, check them, and publish them (using the local pypi server and npm --dry-run, and bypass any GitHub release activity.

Packages uploaded multiple times

I just updated my fork of jupyter_releaser to the latest, and trying to release jupyverse fails. It looks like it's uploading the packages again and again. For instance, fps-auth was uploaded several times, and I can see that the version is there on PyPI, but then we get a 403.
I'm not sure why it is uploaded several times, any idea?

Allow overriding install options on upstream

Problem

Downstream on jupyterlab, all PR builds are failing because of check-release, specifically when trying to do an editable install of the master:

• jupyterlab/jupyterlab#11933

Basically, master is wedged because a transient dependency (pyrsistent) is trying to build from source, and has an under-specified build environment which brings in a "bad" setuptools w/r/t (maybe) distutils. Who knows, half this stuff is vendored, anyway.

This basically can't be fixed aside from hot-patching the dependencies on master.... maybe.

Proposed Solution

Perhaps being able to provide a custom pip install arguments here would help:

https://github.com/jupyter-server/jupyter_releaser/blob/main/jupyter_releaser/lib.py#L568

e.g.

PREP_GIT_BASE_PY_INSTALL: pip install -vv -e ".[test]" "pyrsistent!=0.18.1"

Though it might actually require patches or something to fix this case. No idea.

Additional context

Dunno...

Publish Release: `urllib.error.HTTPError: HTTP Error 502: Bad Gateway`

Description

Recently I have been seeing the following error several times when releasing JupyterLab 4.0.0ax:

urllib.error.HTTPError: HTTP Error 502: Bad Gateway

This error happens during the jupyter-releaser extract-release step.

This sounds like an issue with GitHub, and restarting the workflow a couple of times eventually helped for the previous releases.

Reproduce

Here is an example log of the "Publish Release" run: https://github.com/jtpio/jupyter_releaser/runs/5772374297?check_suite_focus=true

COMMAND: /tmp/tmpxvof53ln/bin/pip install -q dist/jupyterlab-4.0.0a23.tar.gz
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.9.10/x64/bin/jupyter-releaser", line 33, in <module>
    sys.exit(load_entry_point('jupyter-releaser', 'console_scripts', 'jupyter-releaser')())
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/runner/work/jupyter_releaser/jupyter_releaser/jupyter_releaser/cli.py", line 101, in invoke
    super().invoke(ctx)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/runner/work/jupyter_releaser/jupyter_releaser/jupyter_releaser/cli.py", line 615, in extract_release
    lib.extract_release(
  File "/home/runner/work/jupyter_releaser/jupyter_releaser/jupyter_releaser/lib.py", line 364, in extract_release
    for tag in gh.list_tags():
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/ghapi/core.py", line 176, in list_tags
    return self.git.list_matching_refs(f'tags/{prefix}')
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/ghapi/core.py", line 63, in __call__
    return self.client(self.path, self.verb, headers=headers, route=route_p, query=query_p, data=data_p)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/ghapi/core.py", line 108, in __call__
    res,self.recv_hdrs = urlsend(path, verb, headers=headers or None, debug=self.debug, return_headers=True,
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/fastcore/net.py", line 212, in urlsend
    return urlread(req, return_json=return_json, return_headers=return_headers)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/fastcore/net.py", line 111, in urlread
    with urlopen(url, data=data, headers=headers, timeout=timeout, **kwargs) as u: res,hdrs = u.read(),u.headers
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/fastcore/net.py", line 105, in urlopen
    return _opener.open(urlwrap(url, data=data, headers=headers), timeout=timeout)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/urllib/request.py", line 523, in open
    response = meth(req, response)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/urllib/request.py", line 632, in http_response
    response = self.parent.error(
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/urllib/request.py", line 561, in error
    return self._call_chain(*args)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/urllib/request.py", line 494, in _call_chain
    result = func(*args)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/urllib/request.py", line 641, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 502: Bad Gateway
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/runner/work/jupyter_releaser/jupyter_releaser/jupyter_releaser/actions/publish_release.py", line 10, in <module>
    run(f"jupyter-releaser extract-release {release_url}")
  File "/home/runner/work/jupyter_releaser/jupyter_releaser/jupyter_releaser/util.py", line 72, in run
    raise e
  File "/home/runner/work/jupyter_releaser/jupyter_releaser/jupyter_releaser/util.py", line 64, in run
    process = tee(cmd, **kwargs)
  File "/home/runner/work/jupyter_releaser/jupyter_releaser/jupyter_releaser/tee.py", line 172, in run
    raise subprocess.CalledProcessError(
subprocess.CalledProcessError: Command 'jupyter-releaser extract-release https://github.com/jupyterlab/jupyterlab/releases/tag/untagged-7ba22f3a699e86e549f4' returned non-zero exit status 1.

Expected behavior

Not sure this would actually help, but maybe a couple of retries in case the jupyter-releaser extract-release command fails could help mitigate this, and avoid restarting the workflow manually.

Context

Maybe this could be related to the content of the release, for example to many assets to download?

It also happened when releasing JupyterLab 3.3.0 a couple of weeks ago.

But not seen on other repos / projects (yet).

Improve handling of get_version

Problem

We are currently using either the deprecated python setup.py --version or the slow build-a-wheel-and-extract-metadata method to get the current version.

Proposed Solution

Use the approach recommended by setuptools_scm to get the version:

from importlib.metadata import version, PackageNotFoundError

try:
    __version__ = version("package-name")
except PackageNotFoundError:
    # package is not installed
    pass

We'd have to install the package in editable mode so that the version can remain dynamic.

Handle new projects adopting the releaser from the start

Description

For new projects that want to use the releaser from the start, they face the following issue when running the check release workflow on CI:

Reproduce

This can be reproduced by:

• generating a new lab extension from https://github.com/jupyterlab/extension-cookiecutter-ts
• creating a new PR to trigger the check release workflow

Or as an example: https://github.com/jupyterlite/p5-kernel/pull/1/checks?check_run_id=3745163483

Expected behavior

The releaser should handle new repo with no previous release and tag.

Probably we could default to the hash of the first commit if the git --no-pager tag command does not return anything.

Pyproject Integrity Check

Problem

I had some issues this week trying to release terminado. twine check --strict showed no problems, but PyPI rejected due to quotation marks in field contents.

Proposed Solution

We can use validate-pyproject to validate pyproject.toml files.

Comments on the adoption guide

There are small bits I found unclear and would like to ask for clarification:

Bump version configuration (if using Python), for example tbump

thbump is mentioned as optional here, but the rest of the guide seems to suggest it is required for Python; it does not explain what API should be exposed by alternatives. It is also not clear how node package version bumping is handled.

Add a GitHub Access token with access to target GitHub repo to run GitHub Actions, saved as ADMIN_GITHUB_TOKEN in the repository secrets

Which permissions are needed for this token? Does it have to be a PAT token (which AFAIK cannot be scoped per repo), or can we use a deploy key?

Add a GitHub Actions CI step to run the check_release action

Where? In which job it should be contained? What does this action do?

Update or add RELEASE.md that describes the onboarding and release process, e.g.

The example is missing? I guess a link is missing?

We recommend putting setuptools metadata in setup.cfg and using version attr: <package_name>.__version__, see example setup.cfg

Nitpick: version = attr: <package_name>.__version__

Changelog and Full Release in the same workflow

Problem

To push the automation even further, maybe there could be an additional workflow that would create the new changelog entry and do the full release right after?

The changelog entry would be added as a single commit, and the next commit would be the publish commit.

This would slightly change the current workflow of having the changelog entry added as a PR.

Proposed Solution

Probably folks can already do that with the jupyter_releaser CLI already, and that workflow could even live in their repo directly.

So we could either document such workflow, or add it to the releaser repo like the existing ones.

Additional context

cc @martinRenou who was interested in this

Treat Manual Backports the same as Meeseeks Backports

Problem

Manual backports show the manual backport PR instead of the original, because we are looking for the the meeseeks username to resolve backports.

Proposed Solution

The title of the PR should be "Backport PR #{prnumber} on branch {target_branch} ({prtitle})" in either case, so we should look at the PR title using a regex match.