ludrao / django-tellme

Django app that enable user feedback (feedback button)
Other
152 stars 51 forks source link

release by tag #65

Closed thenewguy closed 3 years ago

thenewguy commented 3 years ago

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 commented 3 years ago

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

thenewguy commented 3 years ago

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

thenewguy commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

ludrao commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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