conventional-changelog/commitlint

Commitlint considering `Signed-off-by` as body

Open

#3,411 opened on Oct 24, 2022

View on GitHub
 (10 comments) (2 reactions) (0 assignees)TypeScript (896 forks)batch import
bughelp wanted

Repository metrics

Stars
 (15,497 stars)
PR merge metrics
 (Avg merge 12h 56m) (52 merged PRs in 30d)

Description

I create my commit with the following git commit -s -m "This is a commit message"

Which produces the following commit:

This is a commit message

Signed-off-by:  me@example.com

And a configuration with the following:

module.exports = {
    rules: {
       'body-leading-blank': [2, 'always'],
       'body-empty': [2, 'never'],
    },
};

My expectation is that when I run commitlint I would see an error telling me that there is an empty commit body.

Current Behavior

What I'm currently seeing is that commitlint appears to think that Signed-off-by is the commit body.

Affected packages

  • cli
  • core
  • prompt
  • config-angular

Possible Solution

N/A

Steps to Reproduce (for bugs)

  1. git commit -s -m "This is a commit message"
  2. create config with the above content
  3. commitlint --config -e --verbose

Context

I would like to be able to have commitlint fail on an empty message body. However, I would like to account for the fact that some folks sign their commits and others do not (not currently a requirement).

Your Environment

Executable Version
commitlint --version @commitlint/cli@17.1.2
git --version git version 2.32.0 (Apple Git-132)
node --version v14.17.5

Contributor guide

Research direction
Investigate how commitlint parses commit messages, specifically the header/body/footer separation, and how 'Signed off by' and other trailers are handled. Look at the '@commitlint/parse' package to understand the logic for determining the body. Consider if the body should be empty when only trailers are present.
Tech stack
typescriptjavascriptnodejs
Domain
clitoolingdeveloper experience
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GitNode.js
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
70