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

Rule does not work with #ids #3615

Open
kamathgopal opened this issue May 31, 2023 · 12 comments
Open

Rule does not work with #ids #3615

kamathgopal opened this issue May 31, 2023 · 12 comments

Comments

@kamathgopal
Copy link

I was trying this utility in my project as we are planning to enforce conventional commit messages. It works nicely but I was pleasantly surprised when it started failing miserably. When I tried to commit with messages like git commit -m "#123 - test commit" it does not throw any error. However when I run commitlint --from=HEAD~1 it shows error.

Screenshot 2023-05-31 at 14 34 20

This is causing issues as the team is accustomed to #ticket-id - message pattern.

@escapedcat

This comment was marked as off-topic.

@kamathgopal
Copy link
Author

@escapedcat my issue is commitlint is not throwing any error and accepts it as valid commit message :(

@escapedcat

This comment was marked as off-topic.

@kamathgopal
Copy link
Author

I can confirm there is no issue with husky as it fires correctly before commit. We even have a pre-commit hook for linting staged files. Even commitlint works in most of the scenarios it fails only when I use commit message in above format.

Screenshot 2023-05-31 at 14 58 08

Husky setup is as below

Screenshot 2023-05-31 at 15 01 41

@escapedcat
Copy link
Member

it fails only when I use commit message in above format.

Ooohhhh, I see. I assume commitlint thinks this is a commented out sentence as does not lint it.

@kamathgopal
Copy link
Author

Oh that was not expected :( is there a work around or will this be treated as bug? The same rule works when we run commitlint --from=HEAD~1 weird though.

@escapedcat
Copy link
Member

Uhm, nor sure. I remember there were some adjustments regarding comments in the commit-body. Would be good to have a look what was done there and if this also caused this.
In general this might be a bug I guess.

@kamathgopal
Copy link
Author

Thank you @escapedcat for your quick replies. I will continue with current setup hopefully we get a fix for this in near future :)

@escapedcat
Copy link
Member

hopefully we get a fix for this in near future

Only if someone is motivated to take care of it :P
I'll try to find the PR I mentioned.

@FiscalCoder
Copy link

hopefully we get a fix for this in near future

Only if someone is motivated to take care of it :P I'll try to find the PR I mentioned.

May I offer my assistance with this Git issue, despite being new to open source? I have recently reviewed this codebase to implement custom issue prefixes. I think i might be able to help with some guidance.

@escapedcat
Copy link
Member

escapedcat commented Jun 5, 2023

@kamathgopal which commitlint version are you using?
According to this issue it's fixed: #3208

I just tried this with current master

echo "#123 - test commit" | ./@commitlint/cli/cli.js
⧗   input: #123 - test commit
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

Update:
-m '#123 - test commit' is leading to the bug.
@HoLiSchitz have a look if you have some time.
#3208 might be related.
#2827 as well.

Would be nice to have the same behaviour when running -m or echo "#123 - test commit" | ./@commitlint/cli/cli.js or other ways of linting.

@kamathgopal
Copy link
Author

@escapedcat thanks, I am using the version 17.6.5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants