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

fix: Body line with reference like #123 is considered footer #4099

Open
1 of 4 tasks
Wuestengecko opened this issue Jul 10, 2024 · 2 comments
Open
1 of 4 tasks

fix: Body line with reference like #123 is considered footer #4099

Wuestengecko opened this issue Jul 10, 2024 · 2 comments

Comments

@Wuestengecko
Copy link

Steps to Reproduce

echo 'rules: {footer-leading-blank: [2, always]}' > .commitlintrc.yml
cat > commit-message.txt << EOF
fix: don't frobnicate the foobar

This commit prevents the foobar from being frobnicated
during operation, and therefore fixes #69.
EOF
npx '@commitlint/[email protected]' -e commit-message.txt

Current Behavior

Validation fails with:

⧗   input: fix: don't frobnicate the foobar

This commit prevents the foobar from being frobnicated

during operation, and therefore fixes #69.
✖   footer must have leading blank line [footer-leading-blank]

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

Expected Behavior

Validation passes.

Affected packages

  • cli
  • core
  • prompt
  • config-angular

Possible Solution

No response

Context

Also happens with the full reference format: user/repo#123

commitlint --version

@commitlint/[email protected]

git --version

v2.45.2

node --version

v22.4.0

@escapedcat
Copy link
Member

Does this duplicate or relate to #3695?

@Wuestengecko
Copy link
Author

It might be related, now that I've read the spec more carefully. Without having looked at any code, I think the problematic point is number 10:

A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.

Maybe commitlint also looks for token/separator pairs somewhere in the middle of the line, instead of only at the beginning? The spec isn't really clear on whether that's allowed, and I guess it also depends on how commitlint wants to parse things like

Resolves #10, resolves #123, resolves octo-org/octo-repo#100

which is interpreted by Github. I can see how trying to parse this as three separate footers could easily lead to this kind of confusion in the body.

(Although now I'm not sure if #3695 is actually a bug. The way I read it, "JIRA-1234" is a valid "token", but without a separator and value afterwards, it's not a footer.)

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

No branches or pull requests

2 participants