notes/question on release process

[okken]

I just wanted to check to see if I could do a release, so I just pushed v0.9.2

Process I used:

• Update Changelog with description of new tag, v0.9.2. Push to a forked branch. Merge to primary repo.
• Create release v0.9.2 and with it create the new tag, v0.9.2 through GitHub web interface
• On local machine, git fetch upstream
• pip install twine build
• rm -fr dist/*
• python -m build
• twine upload dist/*

@nicoddemus (or anyone else who cares), does that seem about right?

I wanted to look into having a GitHub action detect a new tag and publish, but that will require access to PyPI "manage" feature of pytest-repeat, which I don't have. I'm ok with manual publishing. I just want to document it. Please let me know if I missed a step.

When the project switches to hatch or flit, the process will change. But I do like the way the version comes from a git tag, so I don't want to change to another workflow unless/until that's supported. I think hatch allows it. Not sure about flit.

[nicoddemus]

The manual process seems fine for 0.9.2.

However moving forward I really think we should strive to have automated builds via GitHub Actions, as it is safer and more practical.

I wanted to look into having a GitHub action detect a new tag and publish, but that will require access to PyPI "manage" feature of pytest-repeat, which I don't have.

With our current permissions on PyPI, we can at least setup an API token for pytest-repeat:

This allows us to use the pypa/gh-action-pypi-publish using that token.

[okken]

Thanks. I forgot that's where the API tokens are.

[RonnyPfannschmidt]

Let's Set up openid connect for it

[nicoddemus]

Let's Set up openid connect for it

That would be ideal, but @davehunt would need to set it up given he is the Owner on PyPI.

[okken]

I don't have enough permission on the github project to save a security key, so even API tokens are not possible, for the time being.

[nicoddemus]

@davehunt can you give @okken the appropriate permissions please?

[nicoddemus]

@okken if you are in a rush to get a new release out, feel free to go with the manual process... however I suspect if you do not have permission rights to generate a token, you won't have permission to upload a package either.

[okken]

I have enough permissions on PyPI to upload, as I did with 0.9.2. I don't have enough to Manage on PyPI, or set up secrets on GH.

I'm not in a rush, for now. But I'd like to settle this before I forget about the details. I'll send Dave an email with a few options.

Options:

1. OpenID connect (preferred): Add me and/or Bruno as an owner on PyPI project (required for one of us to set up OpenID)
2. API token: Add me and/or Bruno as an admin on GitHub project (required for one of us to access "security: secrets and variables", to set up an API token)
3. Dave can be involved. I can set up the workflow file in GitHub, then Dave does the PyPI work to setup OpenID, and be willing to be around if this needs to change.
4. Dave sets this up.
5. We stick with individuals uploading with twine, flit, hatch, etc.

[nicoddemus]

or set up secrets on GH.

Ahh right, overlooked that.

Thanks @okken!

[okken]

Just to close the loop. The project is now using PyPI Trusted Publisher, with a workflow I borrowed from @hynek and attrs

[nicoddemus]

Thanks @okken!

Out of curiosity, any reason why you preferred that workflow other than the one we have for pytest/pytest-mock/pytest-xdist?

[okken]

Mostly it made more sense to me. There are parts of the xdist workflow that I don't quite get. And it seems natural to "create a release" rather than "starting a deploy pipeline manually".

Here are some of my questions:

    env:
      SETUPTOOLS_SCM_PRETEND_VERSION: ${{ github.event.inputs.version }}

Re above: What does that mean? And will that work if a project is using hatch and not setuptools?

Also:

    - name: Publish package to PyPI
      uses: pypa/gh-action-pypi-publish@v1.8.5

    - name: Push tag
      run: |
        git config user.name "pytest bot"
        git config user.email "pytestbot@gmail.com"
        git tag --annotate --message=v${{ github.event.inputs.version }} v${{ github.event.inputs.version }} ${{ github.sha }}
        git push origin v${{ github.event.inputs.version }}

1. Is the publish done before the tagging of the repository?
2. How does the "pytest bot" user work? Do I need to add that user to a repo? Can someone use that for pytest plugins not in pytest-dev? I think pytest-dev plugins should be usable as examples to non pytest-dev pytest plugins, and if some part of the process isn't usable by others, I kinda don't want to do it.

However, I also want to be a pytest team player, and if the other pytest-xdist workflow is important to you, I'm ok with switching.

[nicoddemus]

Re above: What does that mean? And will that work if a project is using hatch and not setuptools?

That's an implementation detail due to Setup tools.

Is the publish done before the tagging of the repository?

Yes, tagging the repository is part of the release process. More than once it happened that we would tag the repository and then the publishing process would fail for one reason or another, so making the tag part of the release process, after the package has been uploaded, has this benefit.

How does the "pytest bot" user work? Do I need to add that user to a repo? Can someone use that for pytest plugins not in pytest-dev? I think pytest-dev plugins should be usable as examples to non pytest-dev pytest plugins, and if some part of the process isn't usable by others, I kinda don't want to do it.

It is just the user name attached to the release tag, it does not mean anything other than "hey this was an automated commit". We could use the owner of the repository, for example.

But all good, just curious -- if you prefer some other workflow, no worries. 👍

[okken]

Thanks for the thoughtful response.