[
https://issues.apache.org/jira/browse/IGNITE-28827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-28827.
---------------------------------------
Resolution: Fixed
[~shishkovilja], thanks for your review!
> Run all PR checks even when the PR conflicts 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
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Problem
> The GitHub Actions checks in .github/workflows/commit-check.yml (Code Style,
> Abandoned Tests,
> Javadocs, .NET, ducktape) are not dispatched for a pull request that
> conflicts with the base
> branch. The status checks never appear, so a contributor whose PR is
> temporarily in conflict
> gets no CI feedback until the conflict is resolved.
> h3. Root cause
> These checks are triggered by the \{{pull_request}} event, which GitHub
> dispatches against the
> *test-merge commit* (PR head merged into base). When the PR conflicts
> (mergeable state DIRTY),
> GitHub cannot compute that merge commit, so no run is created. This is
> independent of what the
> jobs check out — they already check 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 runs in the
> base-branch context and
> does not depend on the test-merge commit.
> h3. Proposed change
> Switch commit-check.yml from \{{pull_request}} to \{{pull_request_target}}.
> That event is the only
> PR-triggered event not gated on the merge commit, so it is the only way to
> dispatch these checks
> on a conflicting PR. All jobs already check out \{{pull_request.head.sha}}.
> h3. Security trade-off
> These jobs build and *run* untrusted PR code (mvnw test, dotnet build, tox).
> Running untrusted
> code under pull_request_target is sensitive, so the workflow is hardened to
> grant no more
> privilege than the \{{pull_request}} event already did:
> * the token is downscoped to \{{permissions: contents: read}} (no write);
> * no \{{secrets.*}} are referenced;
> * the workflow definition is taken from the base branch, so a PR cannot
> modify it.
> A code comment documents this invariant so that secrets / write permissions
> are not added later
> without revisiting the trade-off.
> h3. Notes / follow-ups
> * pull_request_target that builds and runs fork code goes against GitHub's
> default guidance for
> untrusted code; needs confirmation that ASF Infra policy permits it.
> * Required checks / branch protection are unchanged (job names stay the same).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
