Use a PR for Release Commits

[blink1073]

Fixes #505

• Remove the need for ADMIN_GITHUB_TOKEN
• Create a PR and merge it to make the actual changes in populate release
• Create and push the tag as part of finalize release
• Steps:
  • Test this using https://github.com/blink1073/test-python-project
  • Get tests to pass
  • Add notes on how to test changes - use the fork and branch as the @
  • Update examples and docs - must always use environment for security - should use trusted publishers
  • Publish this as the v3 tag
  • Update docs and example workflows for the new fine-grained token access

[fcollonval]

Thanks a lot @blink1073 this is a nice improvement; the new token required will indeed be far better.

[jtpio]

The one downside I see is that the PRs themselves are in the name of whoever created the token, but the commits will still be in the name of whichever admin runs the deployment.

Hmm in that case maybe we should keep using the bots, so the PRs are opened from the bot account, so it's more "neutral"? Otherwise it would be a bit strange if the GitHub account used for opening the PR does not correspond to the person doing the release.

[blink1073]

We would need to give the bots admin access to the org itself:

[jtpio]

Otherwise a maintainer who wants to make a new release would have to go to the repository settings and put their token. Then after the release remove the secret. The next maintainer would also have to use their token to make a release.

The downside is that this adds a couple more clicks and burden for making a release, but should help associate the PR with the maintainer the release.

[jtpio]

Or maybe the workflow dispatch could take the user token as input as a mandatory field. Although not sure this can be done securely without potentially leaking the token.

[blink1073]

That could be up to the project. Personally, I don't think it would be worth it, since the commits are still in the workflow runner's username.

[fcollonval]

Personally, I don't think it would be worth it, since the commits are still in the workflow runner's username.

👍

[blink1073]

This commit has the docs and example updates: 022cba1 (#521)

[fcollonval]

Thanks @blink1073

[jtpio]

Thanks!

[blink1073]

@fcollonval @jtpio I have an idea: instead of using the personal access token, we can add an option to jupyterlab-probot to close and reopen a PR meeting certain criteria. It already subscribes to Pull Requests and it has access to open/close them. This would trigger the workflows to run, and would require no ongoing maintenance. We can still make the PAT available for folks who don't want to use jupyterlab-probot but still have merge requirements.

[jtpio]

we can add an option to jupyterlab-probot to close and reopen a PR meeting certain criteria

This would also be useful to trigger CI after Playwright snapshots updates: jupyterlab/jupyterlab#13505

[blink1073]

Yeah I like that idea. The alternative would be to add a PAT to the workflow, but I don't think we want to start doing that in general, because it would be easy to introduce a security hole.

[blink1073]

Now that that the PR bot can close/reopen, the next step is to add that as an option, and make the comment if it is given, and update the instructions accordingly.

[blink1073]

I think this actually conflicts with the ability to have silent releases, since we'd have to have a PR instead of a push.

New idea: use the user's GITHUB_TOKEN, and recommend the use of an environment. Technically our check for the github actor's permissions would still work, but environment is still better.

To handle forwardport and silent changelog PRs, we add an option to make the PR comment to toggle the PR.