Provide semantic-release configuration to respect main branch

[latipun7]

I'm submitting a...

[x] Regression 
[ ] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request

Current behavior

The release workflows kind of has false positive. The CI still passes because it's not really an error, but the release not triggered.

Here's the logs:

> semantic-release

[10:01:31 AM] [semantic-release] › ℹ  Running semantic-release version 18.0.0
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/npm"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/github"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/git"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/npm"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/git"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/npm"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/github"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/github"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "success" from "@semantic-release/github"
[10:01:31 AM] [semantic-release] › ✔  Loaded plugin "fail" from "@semantic-release/github"
[10:01:35 AM] [semantic-release] › ℹ  This test run was triggered on the branch main, while semantic-release is configured to only publish from next, alpha, therefore a new version won’t be published.

see: semantic-release/semantic-release#1581

semantic-release not configured to use main branch by default, you need to configure the configs 😉

I have opinionated shareable config too if you don't mind. It's configured to use main branch too alongside with next, alpha, beta, and maintenance version branch (ex: 2.x). It enforces the conventional commits specs and produced this kind of release notes and changelogs.

Expected behavior

No CI error, and the package published to NPM successfully.

What is the motivation / use case for changing the behavior?

New commits not published automatically.

[Nikaple]

It's actually correct this time, because the release was merged from alpha to next (which triggers the release of v2.0.1), and then from next to main (which will trigger v2.0.1 again but that will result in an npm error). So I guess we can delete the next branch, use only one major version, and use @latipun7/releaserc for semantic-release on the main branch?

[latipun7]

So I guess we can delete the next branch, use only one major version

You don't need to delete it with my config. I believe it will release in the main branch as latest dist-tag in npm, but if you release in the next branch, this time the user needs to install your package with next dist-tag, so npm install nest-typed-config@next

To better understand the workflow, here's some nice explanations with examples.
The only difference with my config is, the latest dist-tag configured with the main branch, while next dist-tag is only configured with next branch only. While pre-release dist-tag for alpha & beta is configured in the branch alpha & beta.

and use @latipun7/releaserc for semantic-release on the main branch?

yes, if you agree to use my config, I could make the PR later 😁

[Nikaple]

Yeah definitely. I knew this workflow wasn't the best when I set it up, and even made a few mistakes with releases. Your PR will be very helpful to the project, I'm really appreciated for it!

[Nikaple]

The only difference with my config is, the latest dist-tag configured with the main branch, while next dist-tag is only configured with next branch only. While pre-release dist-tag for alpha & beta is configured in the branch alpha & beta.

At first the release branch was set to main only, but at some point I need next and alpha releases. Then I returned to semantic-release docs again, and found that the default config was somewhat "ok", so I deleted the release branch config. But I didn't notice that it's master branch not main branch in the default config. It's, just, surprising I think.

[github-actions]

🎉 This issue has been resolved in version 2.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀