Add releaser CI scripts #217
Conversation
|
|
|
@martinRenou could you add bot tokens to the repo? |
|
That is a good question 😅 I guess I can't. I don't have rights on the voila-gridstack's PyPI package. Also I don't recall setting up this bot account, maybe @jtpio did? |
|
IIRC you added https://github.com/voila-bot credentials to QuantStack's 1Password. But we still need to wait for Jeremy anyway to add the bot to voila-gridstack's PyPI |
|
@martinRenou let's merge this PR and release gridstack with our tokens? |
|
Yes! Sounds good for now. I think Jeremy did set up the account voila-dashboards/voila#1298 |
|
I don't have manage access to
But with the latest releaser workflows you can now use the PyPI trusted publisher instead of the bot to indicate a release is issued from a specific workflow. This needs to be configured on PyPI by someone with manage access. |
| - name: Finalize Release | ||
| id: finalize-release | ||
| env: | ||
| PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }} |
There was a problem hiding this comment.
Let's update to the latest version of the workflow available here? https://github.com/jupyter-server/jupyter_releaser/blob/main/example-workflows/publish-release.yml
To use the PyPI trusted publishers: https://github.com/jupyter-server/jupyter_releaser/blob/811e16f4194b161331599582ecb30b3de659ac58/example-workflows/publish-release.yml#L18C1-L21
|
@trungleduc @martinRenou does any of you have manage access on the PyPI project to configure the trusted publishers? Or should we request access from another maintainer of the package? |
|
I don't have the manage access to this project. |
Pinging some other maintainers listed on https://pypi.org/project/voila-gridstack/, in case some of them do have more rights: @hbcarlos @JohanMabille @SylvainCorlay @maartenbreddels |
|
Sorry, I checked, and I cannot. |
|
@jtpio let's use the good old token for now? |
trungleduc
force-pushed
the
add-releaser
branch
from
7d810e5
to
7e4fecf
Compare
Which token? The |
|
I guess the only way forward for now if we're stuck is to continue making releases from the fork. Hopefully we'll get more access soon so we can make releases from the repo. |
|
I can add mine to the repo while waiting for the bot |
|
@martinRenou @jtpio should we release the update? |
|
I do have rights now it seems, will setup the trusted publishers logic |
|
Done! |
|
Ah nice. So maybe we can remove the |
| @@ -28,7 +28,7 @@ jobs: | |||
| - name: Install dependencies | |||
| run: | | |||
| python -m pip install --upgrade pip | |||
| python -m pip install jupyter_packaging jupyterlab | |||
| python -m pip install jupyter_packaging "jupyterlab==4.0.12" | |||
There was a problem hiding this comment.
What is the reason for pinning on a particular version?
Should there be a comment to explain why, when we look at it again in the future?
There was a problem hiding this comment.
JupyterLab 4.1 is breaking galata tests here and there.
There was a problem hiding this comment.
What does "breaking" mean? Is it snapshots mismatch? Galata runtime error? Something else?
There was a problem hiding this comment.
I opted for a quick solution to unblock the release process, which we are quite late
There was a problem hiding this comment.
Sounds good to me. Maintaining the tooling around JupyterLab plugins can be painful, and it should not go in the way of getting things done.
Let's debug this separately.
There was a problem hiding this comment.
Sure thanks.
Would you mind posting more information about that "Galata timeout", here or in #220?
Wondering whether this should be fixed upstream in JupyterLab. I also noticed some changes related to the use of Galata downstream (for example in jupyterlite/jupyterlite#1263), so it could be useful to have this information somewhere.
There was a problem hiding this comment.
All the await calls to click on an element have the timeout error.
There was a problem hiding this comment.
Bumping Galata to 5.1.0 fixes the issue
No description provided.