search

eventbrite / eventbrite-sdk-javascript

The official JavaScript SDK for the Eventbrite v3 API
https://www.eventbrite.com/platform/api
MIT License
0 stars 3 forks source link

Look into commitlint #38

Open jonathancreamer-eb opened 6 years ago

jonathancreamer-eb commented 6 years ago

There's a way to use git precommit hooks to validate git commit messages. It's very useful in cases where we're going to use conventional commits, or even potentially over in EDS (although in EDS it'd be cool to move to conventional commits too).

https://github.com/marionebl/commitlint

benmvp commented 6 years ago

I think @kwelch had brought this up way at the beginning. And the issue is that we really want this for PRs, not for individual commits right? Like I want to be able to work on a feature branch and make a dozen commits w/o each one of them having to follow the commit convention. Does commitlint support that? Otherwise I guess I'm gonna have to bypass commit hooks?

kwelch-eb commented 6 years ago

I mostly forgot about that. We could put a bot in place for title linting for PRs only. Here is my original comment on the bot that we could use. https://github.com/eventbrite/eventbrite-sdk-javascript/issues/16#issuecomment-378713637

jonathancreamer-eb commented 6 years ago

Ideally if you're going to be doing conventional commits, each commit with show up as an entry in the CHANGELOG.md.

jonathancreamer-eb commented 6 years ago

And if you don't want a particular commit to show up, then yeah you'd commit -n.

jonathancreamer-eb commented 6 years ago

One of the main benefits of conventional commits is to use https://github.com/conventional-changelog/standard-version, which generates a CHANGELOG.md, and does automatic package.json version bumps.

jonathancreamer-eb commented 6 years ago

This is a nice post about standard-version http://devboosts.com/2017/03/28/conventional-commits/, and an output automatic CHANGELOG.md example... https://github.com/lonelyplanet/backpack-ui/blob/master/CHANGELOG.md.

kwelch-eb commented 6 years ago

I think we mitigate that need by exclusively using squash merge, right?

jonathancreamer-eb commented 6 years ago

That's one possible scenario yea.

benmvp commented 6 years ago

Yeah we squash merge everything, so it's really the PR title that matters.

We're using semantic-release in our .travis.yml for releasing and it creates the Github release for us. Sounds like they're doing the same thing?

kwelch commented 6 years ago

Currently we don't have automated process to ensure that commits are covered properly. However, since we are squashing the time to check that is post merge to be true to it. Is this something that would cover that scenario?

benmvp commented 6 years ago

Re-read that 2nd sentence 3 times and still not 100% sure what you're trying to say 😄

kwelch commented 6 years ago

Oh basically, a bot would cover the title of the PR, but since we are squashing the PR and it allows you to change the title of the commit, we would need to somehow enforce the proper "lint" during that phase of the workflow. It seems like a commit hook would be best to consistently ensure that it will work, but it would be on the GH side not on the local side.