Summary
The Dependabot changelog fallback added in #186 can leave a pull request green without actually persisting a PR-specific changelog entry on the branch.
Problem
We rebased the open Dependabot pull requests after merging the fallback workflow. Those pull requests passed Validate PR Changelog, but they did not receive any auto-generated changelog commit. That means the workflow can currently report success even when the branch still lacks its own notable changelog line for the dependency update.
In practice, we had to add the changelog commits manually afterward to put the PRs into the state we actually want.
Observed Behavior
For Dependabot PRs like #181, #182, and #183:
- the changelog workflow completed successfully;
- no fallback changelog commit was pushed by the workflow;
- the branch still needed a manual changelog commit to reflect the dependency bump itself.
Expected Behavior
One of these must be true for a Dependabot PR before validation reports success:
- the branch already contains its own meaningful changelog entry for the dependency update; or
- the fallback workflow creates, commits, and pushes that entry automatically.
The workflow SHOULD NOT report success while the branch only inherits unrelated Unreleased content from main.
Acceptance Criteria
- Dependabot PR validation fails when the branch has no PR-specific changelog entry and the fallback step does not create one.
- Inherited
Unreleased entries from main do not satisfy Dependabot PR validation by themselves.
- The fallback step only reports success after the branch contains the generated dependency-update entry.
- Tests cover the regression scenario where a Dependabot branch is rebased onto
main after the fallback feature has been merged.
- The workflow summary clearly distinguishes between
already present, auto-created, and missing states.
Notes
This looks like a gap between the intended contract of #186 and the effective state after rebasing Dependabot branches onto a main branch that already contains other Unreleased entries.
Non-goals
- Removing the Dependabot fallback entirely.
- Relaxing changelog requirements for human-authored pull requests.
- Reworking the full changelog authoring model beyond this validation regression.
Summary
The Dependabot changelog fallback added in #186 can leave a pull request green without actually persisting a PR-specific changelog entry on the branch.
Problem
We rebased the open Dependabot pull requests after merging the fallback workflow. Those pull requests passed
Validate PR Changelog, but they did not receive any auto-generated changelog commit. That means the workflow can currently report success even when the branch still lacks its own notable changelog line for the dependency update.In practice, we had to add the changelog commits manually afterward to put the PRs into the state we actually want.
Observed Behavior
For Dependabot PRs like #181, #182, and #183:
Expected Behavior
One of these must be true for a Dependabot PR before validation reports success:
The workflow SHOULD NOT report success while the branch only inherits unrelated
Unreleasedcontent frommain.Acceptance Criteria
Unreleasedentries frommaindo not satisfy Dependabot PR validation by themselves.mainafter the fallback feature has been merged.already present,auto-created, andmissingstates.Notes
This looks like a gap between the intended contract of #186 and the effective state after rebasing Dependabot branches onto a
mainbranch that already contains otherUnreleasedentries.Non-goals