Automated release found nothing to release: check the history the tool can see

How a message becomes a number

Release automation does not guess. It reads the messages of the changes since the last release and applies a rule. Under the Conventional Commits convention, a message beginning fix means a patch, one beginning feat means a minor, and a breaking-change marker, either an exclamation mark after the type or a footer, means a major. Types such as docs, chore or test have no effect on the version unless they also carry a breaking-change marker. Semantic Versioning gives those three increments their meaning: incompatible changes, backward compatible additions and backward compatible fixes. Versions that begin with 0 are described as initial development, where anything may change.

The same rule gives a changelog entry. A changelog is for people, so it should group the changes by kind and say when the release happened, not paste the history.

Why the tool sees nothing

There are four common reasons, and the first is mechanical. A pipeline checkout fetches a single commit by default, so the tool has no history to read and no earlier tag to start from; fetching all history, and the tags, fixes it. Second, tags are missing from the checkout, so the tool believes nothing has ever been released and proposes a first version or none. Third, changes are squash merged: the merge commit takes the pull request title, so the convention has to be applied to titles or the tool reads one vague line per pull request. Fourth, the messages simply do not follow the convention, which is a team habit rather than a pipeline fault.

• Check the checkout depth and whether tags are fetched.
• Check that the last release tag exists in the repository.
• Read the message the merge actually leaves in the history.
• Compare recent messages with the convention.

A dry-run check on a scratch branch

Make a scratch branch and add a handful of synthetic commits that cover each case: a fix, a feature, a documentation change and a breaking change. Write down beforehand which version each case should produce from your current version. Then run the tool in its dry-run mode, which reports the version and the notes without creating a tag or a release, and compare. If the numbers differ, the difference is in the history the tool saw or the rules it applied, not in luck. Run it a second time with no new commits: it should propose nothing.

What fixes it, and what does not

Fixes: fetch full history and tags in the pipeline, agree and write down the convention, apply it to pull request titles if you squash merge, and make the release step run only from the release branch after an approver agrees. Not fixes: editing tags by hand to make the tool agree, forcing a version number with a flag every time, or deleting history. A released version's contents must not be changed, so a mistake ships as a new version, which is why the approval step comes before the first real release.

How the paid outcome is accepted

The fixed job covers one repository with one release branch. It is accepted when a dry run over agreed synthetic commits produces the versions in a table you approved and creates nothing; when the changelog entry groups each change once; when one approved run from the release branch creates exactly one tag and one release record and a repeat run creates nothing; and when nothing can be released from other branches. Publishing to a package registry is excluded unless agreed in writing. It starts at £595, untested, and is paid after you sign off.