build(ci): baseline the Jenkins .claude/ filter on the PR target branch

[lukaszlenart]

Follow-up to #1846 and #1849. The GitHub Actions side is fixed; Jenkins still ran a full Maven round trip on a docs-only PR.

What happens

#1846 guards the two JDK stages on a diff against GIT_PREVIOUS_SUCCESSFUL_COMMIT. For a branch build that is the right baseline. For a PR build it is not — the pointer is the previous head of the same PR, so once the PR is rebased (or the target branch merged into it), everything the target absorbed in between looks like a change of the PR's own.

PR-1848 build #2 is the case. That PR touches only .claude/skills/releasing-struts/, but it had been rebased across the maven.yml fix, and Jenkins computed:

+ base=b633817af047afaa80948404e2e6f1eb78e02b7a
+ git diff --name-only b633817af... HEAD
+ outside=.github/workflows/maven.yml
+ echo true
Changes outside .claude/: true

Both JDK stages then ran in full for a documentation-only change. Since main almost always carries code, this makes the filter useless for any PR that is ever brought up to date — which is most of them.

The fix

Use the merge base with the target branch when CHANGE_TARGET is set. The multibranch checkout already fetches it:

git fetch ... +refs/pull/1848/head:refs/remotes/origin/PR-1848 +refs/heads/main:refs/remotes/origin/main

so origin/$CHANGE_TARGET resolves in the workspace. Branch builds have no target and keep the previous-successful-commit baseline, unchanged.

Fail-open is preserved and now covers the new path too: an unresolvable merge base (target branch absent) leaves base empty and reports true.

Verification

Ran the stage's shell logic against the real commits of #1848 either side of its rebase, and against synthetic heads off main:

case	baseline	result
PR #1848 post-rebase (58a9a013a)	7411024c9	false — was true
PR #1848 pre-rebase (b633817af)	81b34c295	false
PR: code only	7411024c9	true
PR: .claude only	7411024c9	false
PR: .claude + code	7411024c9	true
PR: .claudefoo/ near miss	7411024c9	true
PR: target branch not fetched	none	true (fail open)
branch: no previous successful	none	true (fail open)
branch: previous = origin/main	7411024c9	false
branch: unreachable previous	none	true (fail open)

Not verifiable locally: that Jenkins exports CHANGE_TARGET into the sh step. It is a standard multibranch variable and GIT_PREVIOUS_SUCCESSFUL_COMMIT reaches the same script the same way, so the risk is low — and if it were ever unset, the branch-build path takes over and behaviour is exactly today's. Worth a glance at the Detect changes trace on this PR's own build to confirm.

Only the 7.x line is changed here; support/struts-6-x-x carries none of this.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud