lukaszlenart opened a new pull request, #1850: URL: https://github.com/apache/struts/pull/1850
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](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
