conventional-changelog
Silent false success when git is not present
When git cannot be found in PATH and the user runs commitlint with parameters to read from the git log, commitlint exits with status 0 and no output.
Expected Behavior
When git is needed and cannot be found, commitlint should exit with a non-zero status and print an error.
Current Behavior
When git cannot be found in PATH, commitlint exits with status 0 and no output.
Affected packages
- [x] cli
- [x] core
- [ ] prompt
- [ ] config-angular
Possible Solution
Checking the exit status of git would be a good idea. That takes place in git-raw-commits; I will open a PR there soon.
Steps to Reproduce (for bugs)
- Go to repo
cd /path/to/repo - Add a commit with a bad message
touch foo && git add foo && git commit --no-verify -m 'Bad Commit Msg' - Remove git from PATH somehow, e.g.
sudo mv /usr/bin/git /usr/bin/git.bak - Run commitlint; note zero exit status and no output
commitlint --from HEAD~1 - Don't forget to put git back if needed, e.g.
sudo mv /usr/bin/git.bak /usr/bin/git
Context
The reproduction steps above may make this seem like a convoluted edge case, but it is not too difficult to run into.
I encountered this bug when setting up CI jobs to run in an alpine linux container. The repository is made available to the container via a bind mount and git is not installed by default. I didn't realize at first that git was missing and was confused by commitlint succeeding when it should not.
Another way a dev could be affected by this is if git is uninstalled for some reason (accidental, troubleshooting, etc).
Your Environment
| Executable | Version |
|---|---|
commitlint --version |
@commitlint/[email protected] |
git --version |
git version 2.28.0 |
node --version |
v14.11.0 |
Wonder if we should tag this and #2118 with something like dep-bug or something similar. Or maybe these bugs should be opened in the related repo in the first place?
Wonder if we should tag this and #2118 with something like
dep-bugor something similar. Or maybe these bugs should be opened in the related repo in the first place?
I missed this comment when it was made. I'm not sure to what extent it was directed at me, but I will drop my .02.
Since the bug directly affects users of commitlint (and that is how it was found), I think a bug report here is definitely appropriate.
That isn't to say there shouldn't also be a bug report in the conventional-changelog repo where the git-raw-commits package (and source of this bug) lives. I eschewed doing that since since everything lives under the same organization. If needed I could open a bug report there as well, from the perspective of a consumer of the package rather than a user of commitlint.
I've been thinking about this for a few days. If the issue is definitely in git-raw-commits then I'd rather patch the source of the bug than just patch it here? Given that might be a useful fix for others and we consume dependencies so we don't have to re-write everything all time.
I only would only recommend not doing it here if the fix is specific to commitlint but I'm guessing this could be a downstream problem for other packages that use git-raw-commits.
