fix: ensure git signatures are not present

[adam-moss]

Currently an empty changeset is produced if the git configuration has log.showSignature set to true. This change ensure we set it to false to allow commit header parsing to function correctly.

Further information can be found in

• Parse failing with git config showSignature conventional-changelog/conventional-changelog#213
• fix(git-raw-commits): normalize git show signature option to false conventional-changelog/conventional-changelog#671

Signed-off-by: Adam Moss [email protected]

[adam-moss]

@TimothyJones any chance of a review of this please?

[codecov-commenter]

Codecov Report

Merging #54 (268800b) into master (7fbc106) will not change coverage.
The diff coverage is n/a.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@           Coverage Diff           @@
##           master      #54   +/-   ##
=======================================
  Coverage   97.40%   97.40%           
=======================================
  Files          27       27           
  Lines        1194     1194           
=======================================
  Hits         1163     1163           
  Misses         31       31           

Impacted Files	Coverage Δ
lib/lifecycles/changelog.js	100.00% <ø> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[TimothyJones]

Thanks for the reminder! Much appreciated.

Just to confirm, this fixes an issue where the changelog would incorrectly be empty if there were signed commits?

I'm not too familiar with git signatures - Is it possible to add a test, or would it be too clumsy to create a signed commit?

[adam-moss]

Hi,

So this issue is more if the log.showSignature setting in the git config is true.

When it is the git log will show the signature before the commit, so the change log is always empty because the signature is incorrectly put in as the commit message header, resulting in it never matching against the conventional type

[TimothyJones]

Aha! That makes sense. I’m not at a computer now, but I will merge and release this tomorrow.

[TimothyJones]

Released as 11.1.0, please let me know if there are any issues. Thanks again for the PR!