Unable to create first release due to commitlint

[Ijee]

I am trying to use semantic-release for my side project but I am having trouble getting the first release out due to commitlint throwing an error during the commit-analyzer stage.
The first error I am getting is this one:

• stop algorithm at 10k iterations when clicking complete algorithm (c1c8d19)
  ✖ body's lines must not be longer than 100 characters [body-max-line-length]

I am not sure why it fails on this commit message because it isn't above the 100 character limit but I also didn't
use conventional commits until later while working on this project so fixing this one would most likely also make commitlint throw an error at a later point (220~ commits so far) during the commit-analyzer.

I am not sure if this can be viewed publicly but this is the link to the failed run for more info:
https://github.com/Ijee/Amazeing/actions/runs/8644551156/job/23699917075#step:6:1374

The question I now have is if I can skip all of this for the first release becasue it really doesn't matter for the first release for me.

The semantic-release config I use:
https://github.com/Ijee/Amazeing/blob/main/package.json#L102

The release.yml it uses for the releases at the moment:
https://github.com/Ijee/Amazeing/blob/main/.github/workflows/release.yml

This is probably a dumb question and just me missing something entirely with an easy workaround I just fail to see. Regardless, I hope someone can help me with this because it's a bit frustrating.

[travi]

two recommendations that would save you some complexity and avoid this problem:

• dont run commitlint against automated commits, especially in your CI release workflow (you should only ever run semantic-release from a CI workflow)
• we recommend agaist making commits as part of your release workflow. semantic-release doesnt need them in order to work and doing it anyway introduces several extra complexities that you can avoid by simply not making commits as part of your release

[Ijee]

Oh...
I actually thought that commitlint message was what the commit-analyzer did. As in it would go over all my commits and then block the release due to it not following the right format. I just didn't read it right.
Instead it was the husky commit-msg hook that triggered commitlint and thus always failed the ci run because the git commit message includes all the changes in the commit body by default and thus the reason it way above the 100 character limit it set by default.

I now changed it and it works perfectly. I only used the changelog + git plugin to also generate the changelog.md but that's honestly really not needed. Not having to merge it back to my develop branch afterwards is the right call.

I am usually not the one doing ci changes, etc. so I expected me to fail a bit here and there. But I am also really good at missing some minor problems and then getting stuck.
Thank you!

(Although not using the git plugin and thus not having a commit also means it doesn't update my package.json version if I am not mistaken and I kind of want that to happen).

[travi]

it doesn't update my package.json version if I am not mistaken and I kind of want that to happen

i understand this desire, and it is a common one. still, we recommend against doing this because it sets up your team for an expectation that might not always be met. there are some failure scenarios where the latest version that exists in the registry could be out of sync with what gets updated in the package.json, so using it as the reference for the current version would lead to confusion in that scenario. instead, it is better to consult the registry as the true source of truth for latest version. npm dist-tags ls <package-name> is a great quick command for checking this

[Ijee]

I just read up on this a bit and agree with what you said. Either way thanks for the quick responses to help me out.

The only other thing that I also got stuck on while setting this workflow up was that I didn't know why the --dry-run wasn't working
locally and in the end it was because it was missing the github_token secret. I somehow assumed it would skip those checks/requirements as well to just print out the result for the release.

This is a really nice project and I'll most likely use it in the future for other things as well!
Cheers 👍