Anton Vinogradov created IGNITE-28827:
-----------------------------------------
Summary: Code style (checkstyle) check does not run on pull
requests that conflict with the base branch
Key: IGNITE-28827
URL: https://issues.apache.org/jira/browse/IGNITE-28827
Project: Ignite
Issue Type: Task
Reporter: Anton Vinogradov
Assignee: Anton Vinogradov
h3. Problem
The "Code Style" / checkstyle GitHub Actions check is not dispatched for a pull
request that
has merge conflicts with the base branch. The status check simply never
appears, so a
contributor whose PR is temporarily in conflict gets no code-style feedback
until the conflict
is resolved.
h3. Root cause
The check lives in .github/workflows/commit-check.yml and is triggered by the
\{{pull_request}}
event. For \{{pull_request}}, GitHub dispatches the run against the test-merge
commit (the result
of merging the PR head into the base branch). When the PR conflicts with the
base branch
(mergeable state DIRTY), GitHub cannot compute that merge commit, so no
workflow run is created
at all. This is independent of what the job checks out (the job already checks
out
{\{pull_request.head.sha}}).
For comparison, the "Rolling Upgrade / Protected Classes" check runs fine on
conflicting PRs
because it is triggered by \{{pull_request_target}}, which executes in the
base-branch context and
does not depend on the test-merge commit.
Checkstyle does not conceptually need a clean merge — it only needs the PR
sources. The
limitation is inherited purely from the \{{pull_request}} event semantics.
h3. Proposed solution
Move the code-style + licenses checks into a dedicated workflow triggered by
{\{pull_request_target}} (plus \{{push}} for master/release branches, to keep
coverage on pushes),
so the check is dispatched regardless of merge conflicts.
To keep this as safe as the current \{{pull_request}} event, the new workflow:
* downscopes the token to \{{permissions: contents: read}};
* references no repository secrets;
* still checks out \{{pull_request.head.sha}} and only *compiles* the PR sources
(\{{mvnw test-compile ...}}) — it does not execute tests.
With write permissions and secrets removed, building untrusted fork code grants
no privilege
beyond what the existing \{{pull_request}} job already allows, so no new attack
surface is
introduced. The heavy steps that actually execute PR code (abandoned-tests
check) stay on the
{\{pull_request}} event and are intentionally left untouched.
h3. Notes / follow-ups
* The status check name changes from "Check java code on JDK 17" to
"Check java code style on JDK 17"; branch-protection required-checks must be
updated by Infra.
* \{{pull_request_target}} that builds fork code is sensitive; worth confirming
with ASF Infra.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
