Not sure if it's the same issue, but I was seeing this due to not having the changelog preset package installed as well.

Notes: in order to use a preset it must be installed (for example to use the eslint preset you must install it with npm install conventional-changelog-eslint -D)

Edit: actually just rolled back to 19.0.5 of semantic-release and now it works 🤷

We are seeing this as well. Downgrading to [email protected] does the job for us.

The fact that it exits w/o error makes this particularly tricky to spot.

Hi,

I think I've found the root cause.
Since we started to use Semantic Versioning on older projects, on the initial run SV is analyzing ALL commits from the beginning of development. Analyze commit plugin finishes the job correctly and then release-notes-generator starts. My guess is that it finds some "strangely" formatted commit message that cannot be put into the release notes.
My workaround was to run SV with flag --generate-notes false
- npm install [email protected] @semantic-release/gitlab @semantic-release/changelog
- npx semantic-release --generate-notes false

So it will create let's say 1.0.0 tag without release notes on it (actually it's good for us since we don't need the whole project history on the rn). Then I remove this flag and on every other SV run, since it's now analyzing correctly syntexed commits. it generated the release notes and tags as it should.

I've just faced a similar issue that it does not continue running the next step and no any error message. Workaround by downgrading the version works well for me.

Thank you, everyone 🙏🏻 🙏🏻

I think this might be related to this issue from the get-stream repo. From some local testing, not returning getStream and using something like:

const stream = intoStream.object(parsedCommits).pipe(writer(changelogContext, writerOpts));

const changeLogContent = await stream.toArray();

return changeLogContent.join('');

seemed to solve the issue. This is a suggested method from the get-stream readme as well.

@andrew-welker Can you propose a PR 🙏 ?

as explained in #479 (comment), this appears to have been related to a bug in node that has since been fixed. are folks still seeing this on updated node versions?

Yes, I experienced the same issue two nights ago when running semantic-release from a GitHub workflow with Node v18.16.0 installed. I hadn't made any releases on that repo, and temporarily pinning semantic-release to 21.0.1 resolved it.

Here's the run showing the issue (before I pinned it):
https://github.com/bfra-me/renovate-config/actions/runs/5409671209/jobs/9830088909

I'm also seeing this as well using:

# node -v
v20.3.0

Dropping semantic-release back to 21.0.1 also corrected the error for us.

release-notes-generator from semantic-release 21.0.2 with node 18.16.0 still exhibits the same problem with default configuration for the plugin. It seems that the problem appears when there are more than a certain number of changes that need to be processed for a release, thus resulting in a large amount of notes. This is apparent especially when trying to cut an initial release (1.0.0) from a older repository with a lot of commits.
I solved the issue by manually creating a git tag matching our tagFormat (1.0.0) and pointing to a random commit from some time ago. In our case this resulted in 10x less commits to be considered (450 changes before tagging vs 45 after).

Also running into this issue - it definitely appears to be in consolidating multiple commits and trying to generate a significant release notes.

The problem is fairly difficult and we end up just commenting out release note generator , doing a release without any release notes which is less than ideal.

[4:11:53 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The commit should not trigger a release
[4:11:53 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: feat: adds dedicated rest response type for liquidity pool reserves
[4:11:53 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is minor
[4:11:53 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: feat: adds a dedicated type for liquidity pool information
[4:11:53 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is minor
[4:11:53 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: feat: adds silverton hybrid orderbook support

BREAKING CHANGE: Pool information is now included in orderbook types and websocket messaging
[4:11:53 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is major
[4:11:53 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 973 commits complete: major release
[4:11:53 AM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[4:11:53 AM] [semantic-release] › ℹ  The next release version is 4.0.0-alpha.2
[4:11:53 AM] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"

You can see it just stops after the generate notes step without any error in this case and succeeds but no release is generated.

https://github.com/idexio/idex-sdk-js/actions/runs/8963899307/job/24614859968

In the action you can see it tried to generate notes from our first version (not sure why here but either way, it should not have broken this way and at least given some kind of error).

I believe it to be an issue when trying to merge all the different notes together personally but I haven't tried to dig deeper so far.

It def is odd it analyzed hundreds of commits here as well as its branched off our alpha.1 release.

Could your recent problem be related to the recent breaking changes in conventional-changelog packages? Please be sure you are pinning the major version of packages you are installing along with semantic-release to avoid upgrading before semantic-release ready for the breakages

See #633 for more details