use the library version number to publish to pypi, create a git tag and define a github release #688
Conversation
…r from pyproject.toml is used for publishing to pypi as well as tagging the repo and creating a github release
| shell: bash | ||
| run: | | ||
| proj_version=$(poetry version -s) | ||
| if [ $proj_version != $TAG_VERSION ]; then echo "Version $proj_version, defined in pyproject.toml, does not match TAG $TAG_VERSION of this release"; exit 3; fi | ||
| echo ::set-output name=PROJ_VERSION::$proj_version | ||
| poetry update |
There was a problem hiding this comment.
Dependencies should not be updated blindly at release without testing ...
There was a problem hiding this comment.
In addition to the code quality checks being run on every pull request, it is run as the second step in the release process: make install && make tests
Or is there a different set of testing that you think should occur before release?
There was a problem hiding this comment.
Running poetry update at release is a never ever do that thing. The dependencies version lock file must not differ from the one in the repo ...
There was a problem hiding this comment.
thank you for the careful review! i misread your comment originally.
I had reused that section from the current one on master; I should have scrutinized it better. now updated.
| PYPI_TOKEN: ${{ secrets.PYPI_API_TOKEN }} | ||
|
|
||
| - name: Check if Tag exists 🔍 |
There was a problem hiding this comment.
Since the workflow is triggered at tag push, the tag is always here. Why do you want to add these 2 steps?
The sanity check should be that pyproject.toml version match the tag version. And stop the workflow if not by explicitly setting a chain of id: and needs: at each different steps. The version match can even be the first standalone step.
There was a problem hiding this comment.
Instead of triggering on tag push, I just changed it to triggering on workflow_dispatch; this should allow the releaser to trigger the workflow from the UI or github cli and it will generate and apply the tags all based on the version in pyproject.toml. This should make sure that the tag, the github release and pypi release all use the same version number.
There was a problem hiding this comment.
Then if a tag already exists, the release workflow must fail hard at the beginning: version not bumped correctly and version already released.
| - name: Create and Push Tag 🏷️ | ||
| if: steps.check_tag.outputs.tag_exists == 'false' | ||
| run: | | ||
| TAG="v${{ steps.extract_version.outputs.version }}" |
There was a problem hiding this comment.
| TAG="v${{ steps.extract_version.outputs.version }}" |
| git config user.name "GitHub Actions" | ||
| git config user.email "[email protected]" | ||
| git remote set-url origin https://x-access-token:${GITHUB_TOKEN}@github.com/${{ github.repository }} | ||
| git push origin $TAG |
There was a problem hiding this comment.
| git push origin $TAG | |
| git push origin $PROJ_TAG |
Write permission with the default GH token will also need to be set in the workflow.
Resolving dependencies... Package operations: 0 installs, 5 updates, 0 removals - Updating rpds-py (0.20.0 -> 0.20.1) - Updating charset-normalizer (3.3.2 -> 3.4.0) - Updating packaging (24.1 -> 24.2) - Updating setuptools (75.1.0 -> 75.3.0) - Updating hypothesis (6.112.2 -> 6.113.0) Writing lock file as the poetry.lock file shouldn't change from the one that's been versioned and used to run the tests
…in pyproject.toml, it means that the library with this version was already released and we should fail
|
Not sure about this flow, my preference would be to create a new Github release as the first step which also creates a new tag, then check the diff and let GHA do the job of publishing to PyPi. I believe the current workflow allows this direction. Is there something I'm missing which makes this workflow preferable? |
One of the goal is the avoid to have a release on pypi without having a corresponding tag on the GitHub repo. To achieve it, @ajmirsky has moved everything to the workflow, including tag creation, GH release creation, ...: if one step fails, no release is done anywhere (almost). The automated changelog creation on GH and in the repo is still missing. There's other way to achieve a full releasing automation in the python ecosystem I guess. |
Changes included in this PR
Depending on the project release process, hopefully this change to the publish-to-pypi github workflow will keep things consistent. After the project is published to pypi based on the version number in pyproject.toml, the same value is used to create a tag and a github release.
Impact
Keeps the version number consistent across pypi, git tag and github release by using the version number from pyproject.toml.
Checklist
tested additional functionality separately in a different repo, but since I don't have access to publish to pypi, I can't test the full flow.