commit-analyzer
commit-analyzer copied to clipboard
Exclamation mark (!) after type/scope completely ignores commit
I'm using the following config:
module.exports = {
branches: ['master', 'test_commit'],
repositoryUrl:
'ssh://git@*********',
plugins: [
[
'@semantic-release/commit-analyzer',
{
preset: 'conventionalcommits'
}
],
'@semantic-release/release-notes-generator',
'@semantic-release/changelog',
'@semantic-release/npm',
[
'@semantic-release/git',
{
message:
'chore(release): [XX-000] ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}'
}
]
]
};
This seems to work normally when committing feat: or fix: to trigger minor or patch versions, but when the commit message includes ! after scope it is completely ignored. This is the results of the analysis running on my machine with -d (dryrun)
[12:17:21 PM] [semantic-release] › ℹ Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[12:17:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ Analyzing commit: feat!: add new feature
semantic-release:commit-analyzer Analyzing with default rules +0ms
[12:17:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ The commit should not trigger a release
[12:17:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ Analyzing commit: feat: should trigger mnr
semantic-release:commit-analyzer Analyzing with default rules +1ms
semantic-release:commit-analyzer The rule { type: 'feat', release: 'minor' } match commit with release type 'minor' +0ms
[12:17:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ The release type for the commit is minor
[12:17:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ Analyzing commit: feat!: should trigger mjr
semantic-release:commit-analyzer Analyzing with default rules +0ms
[12:17:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ The commit should not trigger a release
[12:17:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ Analyzing commit: feat!: [XX-1234] Commit test
semantic-release:commit-analyzer Analyzing with default rules +1ms
[12:17:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ The commit should not trigger a release
[12:17:21 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ Analysis of 4 commits complete: minor release
[12:17:21 PM] [semantic-release] › ✔ Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[12:17:21 PM] [semantic-release] › ℹ The next release version is 4.1.0
As you can see above all the commits with feat!: give: The commit should not trigger a release
I'm running with --debug and I see that my config is loaded normally:
semantic-release:plugins options for @semantic-release/commit-analyzer/analyzeCommits: { preset: 'conventionalcommits' } +0ms
[12:17:12 PM] [semantic-release] › ✔ Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
Adding BREAKING CHANGES: <desc> footer is respected normally.
same here https://github.com/eclipse-dataspace-cap/cap-ontology/actions/runs/14783773628/job/41508205848
[9:22:05 PM] [semantic-release] › ℹ Running semantic-release version 24.2.3
[9:22:05 PM] [semantic-release] › ✔ Loaded plugin "verifyConditions" from "semantic-release-export-data"
[9:22:05 PM] [semantic-release] › ✔ Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[9:22:05 PM] [semantic-release] › ✔ Loaded plugin "generateNotes" from "semantic-release-export-data"
[9:22:06 PM] [semantic-release] › ⚠ Run automated release from branch main on repository https://github.com/eclipse-dataspace-cap/cap-ontology.git in dry-run mode
[9:22:06 PM] [semantic-release] › ✔ Allowed to push to the Git repository
[9:22:06 PM] [semantic-release] › ℹ Start step "verifyConditions" of plugin "semantic-release-export-data"
[9:22:06 PM] [semantic-release] › ✔ Completed step "verifyConditions" of plugin "semantic-release-export-data"
[9:22:06 PM] [semantic-release] › ℹ Found git tag v1.0.0 associated with version 1.0.0 on branch main
[9:22:06 PM] [semantic-release] › ℹ Found 4 commits since last release
[9:22:06 PM] [semantic-release] › ℹ Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[...]
[9:22:06 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ Analyzing commit: feat!: turn all range to ObjectProperty except date. Remove mandatory id
[9:22:06 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ The commit should not trigger a release
@ticapix your config appears to be using the default configuration for the commit analyzer. by default, semantic-release uses the angular convention, which does not support this feature. it is specific to the conventionalcommits convention. at minimum, you need to configure the commit analyzer plugin to use the convention you are wanting.
@dimitrisfasoulas i see that you have the commit-analyzer plugin configured to use the conventionalcommits preset and your logs suggest that the configuration is getting properly loaded. those would have been my first suggestions to check, so thank you for providing that information. given that, it isnt obvious to me what would be causing your issue. have you since tracked down the problem? if not, could you provide a public reproduction so that we could take a closer look?
@ticapix your config appears to be using the default configuration for the commit analyzer. by default, semantic-release uses the
angularconvention, which does not support this feature. it is specific to theconventionalcommitsconvention. at minimum, you need to configure the commit analyzer plugin to use the convention you are wanting.
Indeed, thank you. Still doesn't work but maybe it's related to https://github.com/semantic-release-action/next-release-version not to semantic-release/commit-analyzer directly. I opened a ticket there.
Hi and thank you for taking a look. I'm off for the weekend but I'll try to create a min reproduction repo next week.
On Fri, May 2, 2025, 22:04 Matt Travi @.***> wrote:
travi left a comment (semantic-release/commit-analyzer#759) https://github.com/semantic-release/commit-analyzer/issues/759#issuecomment-2847902423
@dimitrisfasoulas https://github.com/dimitrisfasoulas i see that you have the commit-analyzer plugin configured to use the conventionalcommits preset and your logs suggest that the configuration is getting properly loaded. those would have been my first suggestions to check, so thank you for providing that information. given that, it isnt obvious to me what would be causing your issue. have you since tracked down the problem? if not, could you provide a public reproduction so that we could take a closer look?
— Reply to this email directly, view it on GitHub https://github.com/semantic-release/commit-analyzer/issues/759#issuecomment-2847902423, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACUEG4XGQ2Z2ITL5LVGHMRT24O6VLAVCNFSM6AAAAABZKS3VQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBXHEYDENBSGM . You are receiving this because you were mentioned.Message ID: @.***>
I have this same problem. If I revert semantic-release to 23.1.1, then feat! will start to work again.
@dimitrisfasoulas i see that you have the commit-analyzer plugin configured to use the
conventionalcommitspreset and your logs suggest that the configuration is getting properly loaded. those would have been my first suggestions to check, so thank you for providing that information. given that, it isnt obvious to me what would be causing your issue. have you since tracked down the problem? if not, could you provide a public reproduction so that we could take a closer look?
@travi Sorry for the delay; it completely slipped my mind.
Here is a public reproduction repo
I can confirm the issue and that a downgrade to semantic-release@v23 resolves the issue.
It seems that something between commit-analyzer@v12(used by semantic-release@v23) and commit-analyzer@v13(used by semantic-release@v24 and above) seems to break the parsing.
Here are the changes between the versions: Diff
I don't see anything too obvious but it upgrades two dependencies to new major versions. @travi, you are a maintainer of conventional-changelog, right? Do you have an idea what could cause the issue?
semantic-release v24 has been out since may of 2024. v24 did introduce breaking changes, mostly due to changes in the conventional-changelog packages we depend on. however, with those dealt with, there should be no reason for this to still be happening. if there is still a problem, it is almost certainly a conflict with something outside the direct scope of semantic-release
@travi, you are a maintainer of conventional-changelog, right?
no, i'm not. semantic-release does not define the commit conventions, nor do we maintain the conventional-changelog packages that codify those conventions. we simply depend on them so that we can automate version bumps and release notes generation through them.
I can confirm the issue and that a downgrade to
semantic-release@v23resolves the issue.
- are you sure you have
conventional-commitsconfigured as the preset? semantic-release uses the angular preset by default. confirm that it is being loaded by including the --debug flag when executing semantic-release - are you sure you've updated any other semantic-release packages you depend on directly? you also dont need to directly depend on any packages that are included through the base package
- are you sure you've upgraded to the latest version of the conventional-changelog preset you are using? this is an important part of the breaking changes in v24
- do you also use commitlint? if so, do you have it configured to also use the same preset? there is a known conflict with commitlint config since they have not updated to the latest versions of the conventional-changelog packages yet. see https://github.com/conventional-changelog/commitlint/pull/4069 for more detail. try running
npm ls conventional-changelog-conventionalcommitsto see if you have multiple versions in your project
also consider this: are you defining a direct devDependency on semantic-release and the preset you use? semantic-release isnt truly a dev-dependency, but rather a release dependency. for this reason, we recommend installing as part of executing with npx rather than depending directly as a devDependency. this can help avoid conflicts with actual devDependencies, like commitlint because npx installs globally rather than locally by default.