search

django-crispy-forms / crispy-tailwind

A Tailwind template pack for django-crispy-forms
MIT License
369 stars 58 forks source link

Automate releases #72

Closed smithdc1 closed 9 months ago

smithdc1 commented 3 years ago

Hi @carltongibson question on releases.

I used Simon W's cookie cutter for this template and he uses a GitHub action to publish releases to PyPI (you add a release on GH, and this triggers the workflow).

Part of me likes this as I'd rather have a system do it via a script than me manually doing it. To do this, I'd create a key for just this project and add it to the secrets. The only concern (and I dont think it is much) is it means anyone with commit access can add a release and push it to PyPI -- but only via the workflow.

I'm probably being a bit more agressive pushing new boundaries which may be too much...

If your happy I'll try it for this project.

carltongibson commented 3 years ago

Hey @smithdc1.

Up to you. If you prefer it to build & upload locally I don't see a problem.

You can get a deploy key from PyPI. Then add that to GHA as a secret.

Is set it to work on a Tag if possible, rather than a GitHub release, since you can create those at the command line and just push the tag to release.

... anyone with commit access...

Well, yes. But that's only a few people, and "Don't create releases/tags unless we're agreed as a group" is reasonable.

justinmayer commented 3 years ago

Great idea, @smithdc1 and @carltongibson. As a project maintainer myself, I am a big fan of automating package releases. In fact, I presented a talk on this very topic last year at EuroPython 2019 in Basel, Switzerland. 😁

The tendency for package releases to lag behind master is very common in the open-source world and is a problem that I have personally encountered dozens of times... including when the fault is entirely my own, in projects that I maintain! It's a shame because it means there are features and bug fixes in master that nearly nobody is benefiting from, and all because publishing new releases to PyPI adds just enough friction to prevent it from happening frequently enough.

Last year I developed a solution to this problem by creating AutoPub, an open-source project that helps automate package releases upon PR merge. Benefits include:

Perhaps the best part is that all contributors get to issue their own releases. What better way to welcome new contributors than to reward them with a dedicated release composed entirely of their own work?

AutoPub supports GitHub Actions, CircleCI, and Travis CI. Projects currently auto-published via AutoPub include:

... and, of course, AutoPub releases itself via AutoPub.

Here's an example of a recent pull request that includes a RELEASE file. When merged, a new Pelican version will be automatically published: https://github.com/getpelican/pelican/pull/2823/files

As a maintainer, I have been thrilled with the results. Releasing new versions this way may sound radical to some, but speaking personally, there are few things as satisfying in a given day as merging a pull request and having a new GitHub release and PyPI package published automatically.

What do you think? If you find the idea intriguing, I would be happy to submit a PR that adds AutoPub, and you can try it to see how you like it. ✨

carltongibson commented 3 years ago

I think this sort of thing really makes sense when we're changing the template packs, because there are so many edge-cases that they continue to evolve, and every individual change is a win.

smithdc1 commented 3 years ago

My natural tendancy is a bit more cautious but...

to lag behind master is very common in the open-source world

guilty as charged, even if most of it was 'maintenance' there was atleast one bug fix that sat on the shelf for a while.

I'll assume you are in the market for a PR on this :smile:

justinmayer commented 3 years ago

Indeed, it would be a pleasure. I'll submit one in the morrow. ☀️

smithdc1 commented 3 years ago

I'll submit one in the morrow.

If you are up for that, sure. But no urgency from me. I think it is all about sustainability (which incidently I think tool like this can really help). :turtle: :rabbit: :checkered_flag:

justinmayer commented 3 years ago

Quite right. Well said. And in fact, there are a couple of potential AutoPub improvements I want to experiment with, so I'll push up something to review once I've completed those. 🚀

cpina commented 3 years ago

I was thinking of this, and my current thoughts:

As an intermediate idea: releases tagged as "dev" would be good and would help testing the process often as well. In the past for django-crispy-forms I've used what the documentation says https://django-crispy-forms.readthedocs.io/en/latest/install.html#installing-django-crispy-forms for using the "unstable" version and this helped to test and avoid waiting for the final release.

carltongibson commented 3 years ago

Trick is that each PR must include the release notes if it's going to go out by itself...

I could go either way here.

justinmayer commented 3 years ago

As @carltongibson mentioned, it's not that every PR merge triggers a release — only those that contain a valid RELEASE file. Which by the way is also the file via which changelog writing/fixing can be made. As for stable releases needing some human input… Even in this model, all releases require human input — either by merging a PR containing a RELEASE file or by directly pushing a RELEASE file to the main branch. So all the items mentioned about double-checking, etc. can absolutely be done via this workflow.

Taking a broader perspective, I personally think too much time is spent tweaking, optimizing, and trying to make things perfect. People repeat the "release early and often" mantra, but in reality, few folks actually do that. After nearly a decade of releasing open-source software, I have come to appreciate the power of releasing first and then fixing things if needed. It's not a "move fast and break things" mentality, but rather truly taking the notion of "release early and often" and actually putting it into practice. Just my two cents, of course. 😊

carltongibson commented 3 years ago

... it's not that every PR merge triggers a release — only those that contain a valid RELEASE file.

At this point you're talking about tooling I'm not familiar with (and I didn't follow the details earlier, you'll have to forgive me 🙂) — I'll wait for the follow-up PR to look more.

What I've used well in the past is to release on Tag. This allows you to take the time to make sure the release notes are ready, and then tag and push to release. It's sufficiently lightweight, so you can get used to releasing often.

Anyhow... let's see what you propose. Thanks! 👍

smithdc1 commented 3 years ago

Great conversation here.

The big win here is the automation of the release. The button you press to start the work flow (tags, GH release, an appropriately constructed PR) is a second order thing in my eyes.

Justin - can your tool make a GitHub release as well? (I'm assuming that's not part of the API as you want to load in the release notes but...)

cpina commented 3 years ago

I think that we all agree.

One quick clarification (or just two examples) on an earlier message that I posted:

* I'm less sure about automatic stable releases on PR merges. I think that a stable release might need some human input: changelog writing/fixing, know if a new PR is coming that makes sense to bundle it all together, have a final look at fixes before saying this is stable... I know that each PR independently should be ok but a bit of "double checking" and "stabilizing" might help.

For the changelog writing I was thinking for things like: I think that we all agree :-)

I've seen attempts of auto generation of changelogs but I haven't followed up how they were used. For another time in my opinion.

Maybe I have spent too much time years ago writing/discussing release note for certain software where the release notes were shown to all non-technical users when the software was being executed so we were spending time preparing them.

GitRon commented 9 months ago

@justinmayer We can close this now, right?

justinmayer commented 9 months ago

@GitRon: Yes, releases have now been automated. I just made two additional tweaks via 728a775256035937d3b478a348f4e58e29900f7c and 143fe000419078546ddca772d547916d3208e305, so hopefully everything should be in place 🤞