switch to deploy environment and configure for pypi oidc

[RonnyPfannschmidt]

closes #10871
closes #10870

[bluetech]

They recommend splitting the building and uploading steps to separate jobs, such that only the upload step gets the id-token: write permission. But I can do this later.

LGTM!

[RonnyPfannschmidt]

good point, lets wait with the merge until i have it split

[RonnyPfannschmidt]

i'll squash this one

[nicoddemus]

Can you leave a comment explaining why?

I ask because I think it is fine to do it (generate the contents + publish to GitHub releases) at this point.

[RonnyPfannschmidt]

expanded the comment, ready for merge i think

[nicoddemus]

Thanks @RonnyPfannschmidt!

In #10870 it was mentioned the project needed to be part of the beta... is pytest part of the beta, or this is not a requirement anymore?

[RonnyPfannschmidt]

As beta User im able to add the config

[nicoddemus]

Ahh per-user, makes sense.

[hugovk]

It's now public and open to all 🚀

https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/

[nicoddemus]

Btw this change inspired me to change the deploy of pytest-mock -- deploy is manually triggered, and the tag is pushed by the workflow itself right after the package is published.

I have not tested it yet, but seems like it is more clean that way.

[nicoddemus]

I guess we do not need the deploy environment to build the package?

[nicoddemus]

Might as well update to the latest version:

Suggested change

	uses: pypa/gh-action-pypi-publish@release/v1
	uses: pypa/gh-action-pypi-publish@v1.8.5

(I just tested this version with pytest-mock and it worked flawlessly to publish it to test-pypi with trusted-publishers).

[nicoddemus]

Question:

Our prepare-release-pr creates branches in the form release-X.Y.Z, so I believe this configuration should be in the form release-[0-9].[0-9].[0-9]?

[RonnyPfannschmidt]

@nicoddemus @bluetech i believe we need to cross-check a misunderstanding

after the note i did a re-read on environments and it seems to me we cant actually use them for our deployments as they target branches, not tags

based on my understanding i propose we postpone using environments as they seem to be intended for having long lived branches be deployed regularly instead of managing release brances as we intend to use them

[nicoddemus]

I'm OK with leaving environments out for now, however I think environments can work as we intend.

I changed pytest-mock deployment to using a manual deploy trigger, which is expected to be executed only in branches in the form release-X.Y.Z (this is configured in the environment as release-*, but can be updated to release-[0-9].[0-9].[0-9] of course).

The workflow in pytest-mock is then:

1. Open a PR preparing a release, in a branch named release-VERSION, updating the changelog (similar to pytest's except there this process is manual).
2. Once all tests pass, trigger the deploy workflow manually, in the release-VERSION branch. The deploy step is dependent on the deploy environment, so its restrictions apply: it can only be triggered over branches named release-*, and it requires approvals.
3. Once approved, the workflow starts.

One important difference from the previous workflow (and pytest's) is that this workflow pushes the tag after the package is pushed to PyPI, instead of the workflow being triggered by a tag. This is cleaner than what we have today, because if anything wrong happens with the release, the tag is already in the repository.

Here is the workflow file in case you want to take a look:

https://github.com/pytest-dev/pytest-mock/blob/main/.github/workflows/deploy.yml

Here is the environment configuration:

One neat thing we gain by using Environments is a deployment history page:

https://github.com/pytest-dev/pytest-mock/deployments

(Not very useful in our case, but neat nonetheless).

---

Having said all that, I'm fine with removing the use of Environment now, and changing the workflow later to be triggered manually.

[RonnyPfannschmidt]

Looks lovely

We might want to adapt this for pytest

In particular if we can let approval trigger the release we could do a setup where the next potential release is always prepared and we only need to have core do multi approval to get it out of the door

We could probably even go as far as having a test pypi of those always be prepared

[RonnyPfannschmidt]

So my proposal is that for this Mr I prepare the config without environments

However we will leave the oidc config for the environment in pypi intact so we can add the enhanced release workflows as follow up whenever we want/can

[nicoddemus]

In particular if we can let approval trigger the release we could do a setup where the next potential release is always prepared and we only need to have core do multi approval to get it out of the door

You mean whenever we merge to master or to the latest maintenance branch (7.3.x now), we automatically run the prepare-release-pr workflow, to update existing PRs which is always up-to-date and ready for release? Sounds good. It can be done easily today I think, we just need to change the triggers for prepare-release-pr and small adjustments to automatically find the version based on current tags/branch.

So my proposal is that for this Mr I prepare the config without environments
However we will leave the oidc config for the environment in pypi intact so we can add the enhanced release workflows as follow up whenever we want/can

Basically just remove the environment keys from the build and deploy jobs, correct? If so I agree. 👍

[RonnyPfannschmidt]

Exactly

[RonnyPfannschmidt]

@nicoddemus @bluetech i finally implemented the review comments and rebased
additionally i added the oidc for no environment

once this lands and we released pytest using oidc, im going to work on moving pytest to the pytest-dev org on pypi

[nicoddemus]

Sounds good.

I would be happy to change the workflow in a separate PR to the one we have in pytest-xdist.

[nicoddemus]

@RonnyPfannschmidt gentle ping, just stumbled on this and thought would give a ping in case this was forgotten.

[RonnyPfannschmidt]

@nicoddemus thanks for the ping, lets merge this once its green

[nicoddemus]

This needs to be manually backported:

To https://github.com/pytest-dev/pytest
! [remote rejected] backport-10925-to-7.4.x -> backport-10925-to-7.4.x (refusing to allow a GitHub App to create or update workflow .github/workflows/deploy.yml without workflows permission)

On it.