Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look into commitlint #38

Open
jonathancreamer-eb opened this issue Jul 2, 2018 · 12 comments
Open

Look into commitlint #38

jonathancreamer-eb opened this issue Jul 2, 2018 · 12 comments
Labels
enhancement New feature or request

Comments

@jonathancreamer-eb
Copy link

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

@jonathancreamer-eb jonathancreamer-eb added the enhancement New feature or request label Jul 2, 2018
@benmvp
Copy link
Contributor

benmvp commented Jul 2, 2018

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
Copy link
Contributor

kwelch-eb commented Jul 2, 2018

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. #16 (comment)

@jonathancreamer-eb
Copy link
Author

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

@jonathancreamer-eb
Copy link
Author

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

@jonathancreamer-eb
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

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

@jonathancreamer-eb
Copy link
Author

That's one possible scenario yea.

@benmvp
Copy link
Contributor

benmvp commented Jul 2, 2018

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
Copy link
Contributor

kwelch commented Jul 3, 2018

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
Copy link
Contributor

benmvp commented Jul 3, 2018

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

@kwelch
Copy link
Contributor

kwelch commented Jul 3, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants