nextchanges: Attribute stacked-PR fragments to the PR that added them - #6546
Merged
Conversation
validate_nextchanges.py required every fragment's trailing PR link to name the current PR. For a gh-stacked PR, the fragments inherited from earlier PRs in the stack are added by ordinary branch commits (no squash "(#N)" subject), so they were mis-attributed to the top PR and CI failed even though each fragment already linked its own PR. For example, #6544 failed because it carried #6448's SDK-bump fragment: "trailing PR link #6448 must include the PR that added this fragment (#6544)". Attribute a fragment to the current PR only when it isn't already present on the PR's base branch; a fragment inherited from an earlier PR in the stack keeps its own link and is no longer re-checked against the top PR. The base branch is BASE_REF (github.event.pull_request.base.ref) in CI, or a best-effort gh lookup locally. Co-authored-by: Isaac <no-reply@databricks.com>
Collaborator
Integration test reportCommit: 819d6a5
Top 10 slowest tests (at least 2 minutes):
|
Contributor
|
Sometimes there is a reason to include more PRs,
will this script accept this? |
Member
Author
@denik Yes, this is already accepted and this PR simply allows gh stack. Tested to verify all following (still) scenarios work:
|
janniklasrose
commented
Sep 7, 2026
Print the error to stderr before returning False so a git tooling failure is visible in CI logs, matching current_branch_pr / current_branch_base. Co-authored-by: Isaac <no-reply@databricks.com>
andrewnester
approved these changes
Sep 9, 2026
Collaborator
Integration test reportCommit: 34d3c3b
498 interesting tests: 415 MISS, 81 FAIL, 1 KNOWN, 1 SKIP
Top 50 slowest tests (at least 2 minutes):
|
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
4 participants
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.
Changes
Fix
tools/validate_nextchanges.pyto attribute each.nextchanges/fragmentto the PR that actually introduced it, rather than always the current PR.
The changelog-preview check requires every fragment's trailing PR link to name
the current PR. It infers the expected PR from the squash-merge commit subject
(
(#N)), falling back to the current PR for fragments not yet on main. Thatfallback is wrong for a gh-stacked PR: the fragments inherited from earlier
PRs in the stack are added by ordinary branch commits (no
(#N)subject), sothey were attributed to the top PR — and CI failed even though each fragment
already carried the correct link to the earlier PR.
Concretely, #6544 (stacked on the
SDK bump #6448) failed with:
Fix
A fragment that already exists on the PR's base branch was introduced by an
earlier PR (upstream, or lower in the stack), so it is no longer attributed to
the current PR — it keeps its own link and is only required to be well-formed.
Fragments the PR genuinely adds still must name the current PR, as before.
infer_expected_prreturnsNone(no specific PR imposed) when the fragmentis present on the base branch (
fragment_on_base), instead of falling back tothe current PR.
BASE_REF(github.event.pull_request.base.ref) in CI, ora best-effort
ghlookup locally (detect_base_ref/current_branch_base,mirroring the existing PR detection).
BASE_REFto the validate step.Behavior is unchanged for non-stacked PRs, pushes to main (fragments keep their
(#N)attribution), and the merge queue's shallow checkout (PR-link checks arealready skipped there).
Tests
python -m doctest tools/validate_nextchanges.py).inherited fragment with the same error as Bump Terraform provider from v1.128.0 to v1.131.0 #6544; with
BASE_REFset to thebase branch it passes. The genuinely-new fragment still requires the top PR's
link.
This pull request and its description were written by Isaac.