search

jaredpalmer / tsdx

Zero-config CLI for TypeScript package development
https://tsdx.io
MIT License
11.25k stars 508 forks source link

Release automation #254

Open jaredpalmer opened 4 years ago

jaredpalmer commented 4 years ago

Continuing on this https://github.com/jaredpalmer/tsdx/issues/85

It would be great to automate releases so that @sw-yx can cut releases as well.

jaredpalmer commented 4 years ago

I think intuit has a cool thing with labels now called like auto. Worth a try?

jaredpalmer commented 4 years ago

https://github.com/intuit/auto

jaredpalmer commented 4 years ago

and perhaps this: https://github.com/auto-it/autobot

swyxio commented 4 years ago

don't we already use circleci? i think kentcdodds uses circle to do his release automation. i've never actually added this to any of my npm projects tho, would be cool to add this. what are the requirements in your mind? i thought you originally didnt want release automation

puregarlic commented 4 years ago

I'd love to help out with this if possible. I've previously used semantic-release to do automated package releases, and it would be pretty easy to configure a GitHub Actions job based on either that or one of the other tools mentioned by @jaredpalmer. I'd say auto is the best option, since it's probably not reasonable to hold everyone to conventional commits.

If we were to use auto and a continuous release process, I imagine that it would look something like this:

  1. A contributor opens a pull request to tsdx master
  2. The Labeler GitHub Action runs, matching against different file paths to determine the PR's changelog section. We won't be able to determine whether it's major, minor, or patch from this check, since that requires maintainer discretion, but we'll at least be able to sort out most internal or documentation changes.
  3. A required "Check Release Status" GitHub Action runs, failing if there's no auto-sanctioned label attached to the PR. See here for that list.
  4. Repeat the usual review -> request changes -> re-review workflow
  5. A maintainer applies a version label to the pull request once it's ready to merge
  6. The "Check Release Status" Action runs again, this time passing because auto's requirements for a release are now met
  7. A maintainer merges the branch
  8. A "Release" Action is initiated that runs auto shipit on the master branch

That's my initial vision for the process, at least. Is that kind of what you guys are looking for?

agilgur5 commented 4 years ago

dripip from Prisma has a really interesting flow where basically all PRs can be pre-released without needing a full publish/release process (deciding semver, release notes, batching multiple changes into one release, etc), allowing people to unblock themselves when necessary.

I do like auto's changelog. I auto-generate mine with my fork of changelog-maker, but it's not as nice as I'd like it to be. Release Notes are contained in the version change commit.

np was added in #582 , that's more of a local publishing thing though, as CI wouldn't need all the same steps and runs a bit differently

jasonkuhrt commented 4 years ago

Hey, lead author of dripip here. By total coincidence found your comment @agilgur5 😅.

We're going to be shipping changelog management in Q2. If there are blocking issues for you that absent would make dripip your choice, let me know, we can probably prioritize them.

johnnyBira commented 4 years ago

Any progress on this one?

jaredpalmer commented 4 years ago

Dripip looks cool. Let’s do that

jasonkuhrt commented 4 years ago

Hey @jaredpalmer I'd like to close a few outstanding issues if you're going to take it on. What's your ETA? I'll need a few days ideally. :)