release by tag

[thenewguy]

This adjusts the tox workflow to manage releases based on tags.

It creates pre-release for tags starting with "p". It creates release for tags started with "v" and publishes them to pypi. The workflow is named "sdist" to reflect it only operates on the sdist. The workflow would need to be duplicated to release a wheel.

[thenewguy]

@ludrao this should work by tags as you prefer - I haven't tried a release so it may need to be tweaked

[thenewguy]

This isn't ready to be merged - isn't picking up the pre-release tag

[thenewguy]

Ah, just have to be patient. It does pick up the tag and pre/release appropriately

https://github.com/thenewguy/django-tellme/actions?query=workflow%3A%22Build%2C+Test%2C+and+Release+sdist%22

[ludrao]

Well honestly I was preferring the other release method that I had done, and tested 'it was working :-/) I find it easier to separate the problems in smaller pieces, so having a very simple gh action just for release seemed more appropriate. I have the impression that the current tox gh action does too many things.

Would you be okey restoring the publish-python script that I did and trim down the tow to only run the test in pull requests ?

[thenewguy]

@ludrao I am happy with whatever you like as it is your project. But I don't understand. You want to upload a different sdist to pypi than the one you run tests against?

This action generates the sdist as one step and then shuffles across the actions so you are always operating on "that" specific package. I don't believe you can transfer the file to your "publish-python" script with github actions.

[thenewguy]

I was thinking about how to make that work. We can probably create the release to GitHub and upload the sdist in this job.

There is an action event that can triggers jobs so the "publish-python" should be able to trigger afterwards. I think we will have access to the tested sdist from the release tag

-- edit --

looks like there is an action available to make this happen https://github.com/marketplace/actions/download-workflow-artifact

hopefully the timing works out

-- edit --

eh, the event that would make this work without being hacky is in development per https://github.com/github/roadmap/issues/94 - the "package" events https://docs.github.com/en/actions/reference/events-that-trigger-workflows#registry_package

in the meantime one could run the pypi release whenever a release is edited. I will remove the release management from the action and we can use your publish script to create a new sdist instead of uploading the testing sdist since you want to keep them separate

[thenewguy]

Ok - pulled out the pypi part. The part I left in just attaches the tested sdist to the tag record on github

[ludrao]

Hi @thenewguy , yes actually I was thinking to decouple the test run from the release. So indeed it might seem 'dangerous' but on the other hand it allows for a quick release. The idea is that I would not publish a release without running the test first. There is also a button gh action, so we could run the test on the master branch triggered by the button.

As for running the test automatically on the PR I did not check but I think that should be douable easily as well.

[thenewguy]

@ludrao Okay - feel free to modify this PR to fit your liking. I think it is doing what you are saying but I am not sure. So I will hold off and let you merge it

[thenewguy]

@ludrao ping - happy with this?

pypi is handled separately.

tested sdists are posted to the github releases. tags for releases start with "v". Tags for pre-release start with "p". Attaching the sdist to the release allows for easy deploy to a staging environment by providing the package name to pip like https://github.com/thenewguy/django-tellme/releases/download/p0.7.0-7/django-tellme-sdist-14-6e5df7a4a7c07dc5404b4adc17c71583c8895c19.zip#egg=django-tellme

[thenewguy]

Going to merge this. I think it implements what you wanted