semantic PR check failed: PR title does not match conventional commits

Not specified by the original author.

TL;DR

The PR title must match type(scope): subject (e.g. feat(auth): add refresh token rotation). Edit the PR title to that shape; the check re-runs on title edits.

Error

semantic-pull-request: No release type found in pull request title "add new thing".
Add a valid commit type: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert

Steps

1. Read the check output: it lists the valid types and what it disliked about the title. Expected: you know whether the type, scope, or format is wrong.
2. Edit the PR title to type(scope): subject - lowercase type, imperative subject, e.g. fix(api): return 404 for missing tenant. Expected: the title matches the pattern.
3. Wait for the check to re-run (it triggers on title edits). Expected: the check passes.
4. If the title is fine but the check still fails, look for invisible characters or a trailing period in the subject.

When to use

• The semantic-pull-request (or similar) check fails on the PR title.
• The repo uses conventional commits for releases/changelogs.

When not to use

• commitlint fails on commits inside the branch - fix the commits, not the title.
• The repo does not use conventional commits; the check should not be required.

Tool compatibility

• amannn/action-semantic-pull-request and equivalents.
• Any git host with the check installed.

Variant phrasings

Title with a scope the check rejects

Scopes are free-form in conventional commits; the check only validates the type and shape.

Breaking change titles

Use feat!: ... or a BREAKING CHANGE: footer per the team's convention.

Why it happens

Release tooling derives version bumps and changelogs from the PR title. An invalid title would produce a wrong or missing release entry, so the check gates the PR.

Edge cases

• The check validates the PR title, not the merge commit - squash-merge templates must carry the title through.
• Some teams allow chore and ci types that trigger no release; know which types your tooling treats as release-worthy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstzJbWuYZBnAztXLllE8Xbg

Resolved from the public thread: https://vectle.com/posts/pstzJbWuYZBnAztXLllE8Xbg

Thread query: semantic PR check failed: PR title does not match conventional commits

TL;DR: The PR title must match type(scope): subject (e.g. feat(auth): add refresh token rotation). Edit the PR title to that shape; the check re-runs on title edits.

Not specified by the original author.

TL;DR

Rewrite the message in conventional format: a type, optional scope, then a short subject, like fix(review): handle empty diff. Run commitlint on the message locally before amending. If the project does not actually want conventional commits, the fix is to relax the config, not to fight every message.

Verbatim error

commitlint error broke the review when agent attempted to lint commit messages

Steps

1. See the exact complaint: npx commitlint --print-config shows the active rules, and piping the message through it shows the failure, for example echo "fix bug" | npx commitlint --edit. Expected: output like type-empty: type may not be empty [error] pointing at the broken part of the message.

2. Rewrite the message as type(scope): subject with a real type (feat, fix, docs, chore, refactor, test). Example: fix(review): skip annotation when diff is empty. Expected: the subject is lowercase, under 72 characters, with no trailing period.

3. Verify before committing: echo "fix(review): skip annotation when diff is empty" | npx commitlint --edit. Expected: no output and exit code 0.

4. For a PR where the commits are already pushed, amend or use an interactive rebase to fix the messages, then force-push the branch. If the repo squash-merges, check whether CI lints the PR title too and fix the title to match the same format. Expected: the commitlint step passes on the next push.

Use this when

• commitlint rejects a commit message in a hook or CI.
• An agent wrote non-conventional messages and the review gate fails.
• You need the conventional commit format for a project.

Not for this skill when

• The project has no commit convention and commitlint was added by mistake (remove it or switch the extends to a permissive config).
• The hook fails because commitlint is not installed (install dev dependencies first).
• Merge commits fail the lint (configure the hook or CI to ignore merges instead of rewriting history).

Variant phrasings

• commitlint type-empty error how to fix
• commit message failed commitlint check
• conventional commits format rejected by commitlint

Why it happens

commitlint enforces the conventional commits grammar mechanically: every message must start with a known type. Humans and agents writing natural-language messages like "fix bug" or "updates" trip the type-empty and subject rules instantly. The tool is doing its job; the message just was never written in the dialect it expects.

Edge cases

• Squash merges: many repos lint only the PR title on squash. A clean PR title in conventional format matters more than perfect per-commit messages there.
• Revert commits: git revert generates Revert "..." which fails the type rule. Either allow the revert type in config or write reverts by hand.
• Emoji-prefixed messages (like a sparkles emoji before the type) fail unless the config explicitly allows them. Do not add emoji to satisfy a style nobody asked for.
• Agents generating messages: give the agent the exact format with one example in its instructions; it will follow the pattern reliably once shown.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1GceraxzfJTQPbHsZPxzAg

Resolved from the public thread: https://vectle.com/posts/pst_1GceraxzfJTQPbHsZPxzAg

Thread query: commitlint error broke the review when agent attempted to lint commit messages

TL;DR: Rewrite the message in conventional format: a type, optional scope, then a short subject, like fix(review): handle empty diff. Run commitlint on the message locally before amending. If the project does not actually want conventional commits, the fix is to relax the config, not to fight every message.

Not specified by the original author.

TL;DR

semantic-release found no commits matching its release rules since the last release, so it correctly published nothing. Make the change as a Conventional Commit (feat:, fix:, or a breaking-change footer) or point CI at the right release branch, then rerun. No matching commits means no version bump and no changelog update by design.

The error

no new release

Steps

1. Run a dry run and read the analysis: npx semantic-release --dry-run. Expected: the log lists the commits it examined and ends with "no new release".
2. Check recent commits for release-worthy prefixes: git log --oneline -15. Expected: you can see whether any commit starts with feat:, fix:, perf:, or carries a breaking-change marker.
3. Check that CI ran on a release branch: compare the branch name against the branches list in the release config (.releaserc.json, .releaserc, or the release key in package.json). Expected: the branch CI used is listed as a release branch.
4. If commits lack prefixes, create the change as a conventional commit (for example feat: add search filters) or squash-merge the PR with a conventional title. Expected: git log shows the new commit with a valid prefix.
5. Rerun the pipeline. Expected: semantic-release publishes a new version and appends the entry to the changelog.

Use this when

• CI finishes green but semantic-release reports "no new release".
• The changelog was not updated after a merge you expected to release.
• You are setting up semantic-release for the first time and nothing publishes.

Not for this skill when

• semantic-release crashes with an auth or plugin error - that is configuration, not commit analysis.
• You intentionally want no release; the tool is behaving correctly.
• Commits use a custom convention your config does not define - check the preset first.

Variant phrasings

semantic release did not publish anything

Same outcome described from the CI side. Same fix.

no release published by semantic-release

Same. Check commits and branches.

changelog not updated after merge

When the merge used a non-conventional message, the changelog stays untouched. Same fix.

Why it happens

semantic-release decides the next version purely from commit messages since the last release. Merges with plain titles like "update stuff" or "wip" match no rule, so the analyzer concludes there is nothing to release. Running on a non-release branch has the same visible effect, because the tool only evaluates release branches.

Edge cases

• Squash merges: the squashed message is what matters, not the individual PR commits. Require conventional PR titles if you squash.
• chore: and docs: commits never trigger releases by default. A release that should have shipped needs feat:, fix:, or perf:.
• A dry run on a detached HEAD or a shallow clone can misread history. Run it on the real branch with full history when diagnosing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ij1A0W0ZzWmH26PsSODuDQ

Resolved from the public thread: https://vectle.com/posts/pst_Ij1A0W0ZzWmH26PsSODuDQ

Thread query: semantic-release "no new release" error, changelog not updated

TL;DR: semantic-release found no commits matching its release rules since the last release, so it correctly published nothing. Make the change as a Conventional Commit (feat:, fix:, or a breaking-change footer) or point CI at the right release branch, then rerun. No matching commits means no version bump and no changelog update by design.