search

jupyter-server / jupyter_releaser

A set of helper scripts and GitHub Actions to aid in automated releases of Python and npm packages.
https://jupyter-releaser.readthedocs.io/en/latest/
Other
45 stars 64 forks source link

Populate release as part of the `Step 1: Prep Release` workflow? #552

Open jtpio opened 5 months ago

jtpio commented 5 months ago

Problem

Running the Step 1: Prep Release is a good way to check the version is correctly bumped, and the changelog correctly created.

However this workflow does not populate the draft GitHub release with the built artifacts (wheel, sdist, npm tarballs), as this is done as part of the populate-release step in the Step 2: Publish Release workflow.

Maintainers might sometimes want to make sure the built assets are correct, and perform some manual checks.

Proposed Solution

This likely does not require any change to the releaser core functionality. Maybe just moving this step:

https://github.com/jupyter-server/jupyter_releaser/blob/8568b9b5017b1a76e9c7af21315ecb04d933886b/example-workflows/publish-release.yml#L25-L32

To this workflow: https://github.com/jupyter-server/jupyter_releaser/blob/main/example-workflows/prep-release.yml

I guess one could try that on a test repo first to see if the whole flow would still work fine.

Additional context

cc @martinRenou who I think was mentioning this after using the python_packages configuration of the releaser for https://github.com/voila-dashboards/voici

blink1073 commented 4 months ago

Yeah, that should work, without any changes to core.

jtpio commented 4 months ago

Maybe one drawback of this approach if that the release commit is pushed during the populate-release step.

Which means that if the maintainer wants to delete the draft GitHub release, they would also have to revert that commit too.

blink1073 commented 4 months ago

Yeah, I don't see a way around that, since the assets are tied to the version bump commit.