Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add release job on tag #21

Merged
merged 1 commit into from
Sep 25, 2024
Merged

Conversation

LiadOz
Copy link
Contributor

@LiadOz LiadOz commented Aug 15, 2024

This workflow will create a distribution and upload it to pypi when a tag is pushed, this does not require setting up API keys in the repository, see more here
In order for this to work the project needs to be registered here https://pypi.org/manage/account/publishing/ with the following parameters:
Screenshot 2024-08-15 at 10 57 26
@vmalloc Before merging this, can you try tagging this commit with a prerelease version to see that it indeed works, I have only tested it with TestPyPI

@vmalloc
Copy link
Owner

vmalloc commented Aug 17, 2024

@LiadOz many thanks for your work on this! I just tested it releasing 1.6.0a1 and it seems to have succeeded!

One question though - isn't the pipeline as it is currently configured going to allow publishing versions that actually fail CI? To my understanding the two chores run in parallel and are not inter-dependent...

@LiadOz
Copy link
Contributor Author

LiadOz commented Aug 26, 2024

@vmalloc I took a look at some of the most prominent python packages to see how they handle version releases with Github actions. I found that there are two approaches, both of these approaches do not test the code before publishing to pypi (they likely rely on the fact that the main branch has already passed the testing pipelines)
Approach 1 - Use publish event, for example https://github.com/python-poetry/poetry/blob/main/.github/workflows/release.yaml
Approach 2 - Use push event and make sure the test pipeline does not trigger on tags https://github.com/python/mypy/blob/master/.github/workflows/build_wheels.yml
I prefer the second approach because it doesn't require you to use the GUI to make a release. Let me know if you want me to use the first approach instead.

@vmalloc
Copy link
Owner

vmalloc commented Aug 28, 2024

All I am concerned about is that currently the publish stage is run in parallel to the build/test phase, which could lead to a release being pushed that retroactively turns out to have failed testing

@LiadOz
Copy link
Contributor Author

LiadOz commented Aug 28, 2024

ok, then approach 1 should fit more here, since the other option will not run the test pipeline

@LiadOz LiadOz force-pushed the liadoz/add-publish-job branch from 7a1afaa to 613091c Compare August 28, 2024 08:38
@LiadOz
Copy link
Contributor Author

LiadOz commented Aug 28, 2024

@vmalloc Now after putting a tag and verifying that the pipeline is ok, you can make a release out of that tag which will publish the package to pypi.

@oren0e
Copy link

oren0e commented Sep 17, 2024

@vmalloc Hi! Do you have an eta when this can be ready? I assume it holds back #20

@vmalloc
Copy link
Owner

vmalloc commented Sep 25, 2024

Sorry for the delay - @LiadOz awesome work - thanks!

I will merge this and cut out the 1.6.0 release now

@vmalloc vmalloc merged commit b798835 into vmalloc:develop Sep 25, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants