fix(generate-changelog): do not fail on release commits or empty changelogs - #78
Open
marc0olo wants to merge 1 commit into
Open
fix(generate-changelog): do not fail on release commits or empty changelogs#78marc0olo wants to merge 1 commit into
marc0olo wants to merge 1 commit into
Conversation
marc0olo
force-pushed
the
fix/generate-changelog-release-commits
branch
from
August 3, 2026 16:59
b010cbc to
fb78c39
Compare
…gelogs
The generate_changelog workflow fires on every push to main, including when a
release PR is merged. Commitizen then has nothing to add to the changelog and
exits non-zero, failing the job. Two variants have been observed in
dfinity/icp-js-core:
- exit 3 ("No commits found") when the tag already exists
- exit 16 ("No tag found to do an incremental changelog") when the tag has not
been pushed yet, which is the common case since the release tag is pushed
manually a couple of minutes after the release PR merges
Both are no-ops in intent, not errors. Two complementary changes:
- Skip the changelog steps entirely when the head commit subject looks like a
release commit, via a new release_commit_pattern input. This covers the exit
16 case, whose cause is the tag not existing yet.
- Treat commitizen exit 3 as success in actions/generate-changelog, so a
release commit that slips past the subject check (retitled release PR, or a
repo that permits merge commits) still does not fail the job.
Exit 16 deliberately remains fatal. Unlike exit 3 it is ambiguous: it also
fires when tags are genuinely unavailable, for example a shallow clone or a
regression in tag fetching. Swallowing it would turn a loud failure into a
silent no-op where the changelog quietly stops being generated.
Closes #75
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
marc0olo
force-pushed
the
fix/generate-changelog-release-commits
branch
from
August 4, 2026 07:30
fb78c39 to
d645d69
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #75.
generate_changelogfires on every push tomain, including release-PR merges. Commitizen then has nothing to add to the changelog and exits non-zero, failing the job. Two variants have occurred indfinity/icp-js-core:No commits found— as reported in #75; those logs have since expiredNo tag found to do an incremental changelog(run)Both are no-ops in intent, not errors.
I could not establish why one release hits 3 and the other 16. The natural theory is "tag already pushed versus not yet", but GitHub reports a release's
createdAtas the tagged commit's date, which says nothing about when the tag was actually pushed. Both changes below are correct regardless of which fires.Changes
1. Skip release commits — new
release_commit_patterninput, defaulting to^chore:[[:space:]]release([[:space:]]|$). When the head commit subject matches, the Setup, Generate and Create-PR steps are skipped.2. Treat exit 3 as success in
actions/generate-changelog, so a release commit that slips past the subject check still does not fail the job.Complementary rather than redundant: the subject check can miss a retitled release PR, or a repo that permits merge commits, where the subject becomes
Merge pull request #N ….Exit 16 deliberately stays fatal. Unlike 3 it is ambiguous — it also fires when tags are genuinely unavailable, for example a shallow clone or a regression in tag fetching. Swallowing it would convert a loud failure into a silent no-op, where changelog generation quietly stops working while the job stays green.
On the default pattern: #75 suggested
^chore:[[:space:]]release. I require a trailing space or end-of-string, because the looser form also matches subjects likechore: release-notes cleanup, which would then be silently skipped. Verified against the real release subjects of all five consuming repos — note that onlyicp-js-coreuses avprefix, so a pattern anchored onrelease vwould silently fail in the other four. Setting the input to an empty string disables the check.Verification
Both files parse as YAML and pass
prettier --check. Exit handling tested under GitHub's shell (bash --noprofile --norc -eo pipefail) with a stubcz: 0 → 0, 3 → 0, 16 → 16, 1 → 1.Not exercised against a live release — that only happens on the next release in a consuming repo.
The other half of the problem, a new branch per run causing pull requests to accumulate, is #77 and is fixed in #80. That PR touches the same workflow file; the two auto-merge cleanly, so whichever lands second only needs a rebase.
🤖 Generated with Claude Code