-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
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 |
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) |
Ideally if you're going to be doing conventional commits, each commit with show up as an entry in the CHANGELOG.md. |
And if you don't want a particular commit to show up, then yeah you'd commit |
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. |
This is a nice post about |
I think we mitigate that need by exclusively using squash merge, right? |
That's one possible scenario yea. |
Yeah we squash merge everything, so it's really the PR title that matters. We're using |
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? |
Re-read that 2nd sentence 3 times and still not 100% sure what you're trying to say 😄 |
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. |
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
The text was updated successfully, but these errors were encountered: