django-crispy-forms / crispy-tailwind

A Tailwind template pack for django-crispy-forms
MIT License
329 stars 56 forks source link

Automate GitHub releases & PyPI package publication #152

Closed justinmayer closed 5 months ago

justinmayer commented 5 months ago

This pull request adds a job to the existing GitHub Actions CI.yml workflow that uses AutoPub to automatically release and publish new packages to PyPI when a release file is merged or pushed into the main branch.

As part of this endeavor, I also took this opportunity to replace the twine upload step with PyPI's new Trusted Publisher system. In addition to the changes in this pull request, the only remaining step needed to utilize the Trusted Publisher system is for someone with more permissions than I currently have to do one of the following two things:

  1. Send me an invitation to join the crispy-tailwind PyPI project with Owner role (my PyPI username is jmayer), after which I would be happy to set everything up.
  2. Since @smithdc1 is currently the only person with access to the PyPI project, David can go to https://pypi.org/manage/project/crispy-tailwind/settings/publishing/, fill out the form with the values below, and submit the form.

Owner: django-crispy-forms Repository name: crispy-tailwind Workflow name: CI.yml Environment name: (optional — can leave this field empty)

Rather than add PDM/Hatch as discussed in #149, I elected to defer that endeavor and instead retain Setuptools as the build back-end for now in an effort to keep the scope as narrow as possible.

Closes #149

justinmayer commented 5 months ago

The idea is not that every single pull request merits a new release. Indeed, you probably don't want a new release to fix a typo in a code comment or to upgrade a linter dependency version. But thankfully that's not how this system is designed to work. 😊

The deployment machinery is only ever triggered when a RELEASE.md file lands in the main branch. That way:

  1. If someone adds a release file when it isn't appropriate, maintainers can use the GitHub UI to remove the RELEASE.md file from a pull request if they feel a new release is not warranted. I do this occasionally, and it takes mere seconds.
  2. If desired, maintainers can easily issue a release manually by pushing a RELEASE.md file directly to main, very similar to what you would expect from a release process based on Git tags.

I will add that I find this process to be much easier than messing with Git tags. You just choose major | minor | patch as the release type in the RELEASE.md file, and the version is automatically incremented accordingly, along with Git tagging, GitHub release creation, change-log updating, and of course package publication to PyPI.

Thanks to Florian, who made a number of improvements to the flow, you can see how this is handled in another Django-related project, Kagi.

carltongibson commented 5 months ago

Gotcha. That's kind of equivalent then. Sounds good. ("Very fancy" 😉)

smithdc1 commented 5 months ago

David can go to ... fill out the form with the values below, and submit the form.

Done!

justinmayer commented 5 months ago

Thanks to Ronny and Carlton for reviewing, and thanks to David for the assistance with the PyPI configuration 💫