[cli] Long commit message bodies cause failure

[jklmli]

Version: 2.12.1

When running yarn validate-commit-msg "$(git log -1 --pretty=%B)", long commit messages cause an ENAMETOOLONG error since the argument is too long.

Failure: https://circleci.com/gh/jiaweihli/monapt/57

[stevemao]

I added this simple command because it works for me and I know it's not perfect :) Send a PR to improve the command :)

[Garbee]

long commit messages

Can you give an example of a "long commit message"? Without a reproducible test case there isn't much that can be done that isn't stabbing in the dark.

Thank you.

[jklmli]

Are you having trouble opening the CI link at http://circleci.com/gh/jiaweihli/monapt/57?

[jklmli]

Ah, I see - there's something buggy with CircleCI.
If you toggle the Validating last commit message section, you can see the console output.

[Garbee]

Long commit message example

``` fix: use generic self-types getOrElse and orElse use self-types in order to support typed upper bounds.[0] In TypeScript 2.4, generic functions were checked more strictly[1]. This causes the implicit downward type cast to fail, so we explicitly invoke the cast in the method body. This workaround is backwards-compatible with TypeScript 2.3. Bounded polymorphism has been implemented[2], but true F-bounded polymorphism hasn't been. This means a type like interface Option> is invalid. Alternatively, we can solve this with a lower type bound, but these don't work against concrete classes[3]. --- We should also upgrade monapt's TypeScript dependency to 2.4, but there are unrelated errors compiling the tests. [0] Microsoft/TypeScript#13337 [1] Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#stricter-checking-for-generic-functions [2] Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#type-parameters-as-constraints [3] Microsoft/TypeScript#14520 ```

There is the commit message in question for testing.

@jiaweihli It is best to provide all the information possible inline without linking to external sources unless required for some reason. That way in case anything externally changes (like a push to that PR to fix the problem) the content of the issue is still whole and debuggable. Also, super useful for reference later to not need to worry about losing stuff.

I'm looking into this now, but I don't think the problem is internally from my initial look at things. It looks like a node problem opening the file due to the length of the path to the file in CI.

[Garbee]

Yup, just tested this message locally and it works as expected. So the problem is somewhere in the CI setup. PRs to address it welcome, but we can't test and debug each CI environment ourselves to fix problems.

Reproduction steps:

1. New directory
2. git init
3. yarn add validate-commit-msg
4. Touch file
5. Add file and commit with the demo message
6. Add validate script to package.json with the value of validate-commit-msg
7. Run set -l IFS; and yarn validate (git log -1 --pretty=%B); and set -e IFS (for fish shell)
8. See passing validation and no error.

[maxcnunes]

@Garbee @jiaweihli I believe my commit solves this problem. At least that was the reason drove me to create that PR.

[hutson]

This package has been deprecated. Please use https://github.com/marionebl/commitlint instead.