+1 for this approach. This also lets non-committers retrigger workflows for potentially flaky tests.
Looking at https://github.com/adoroszlai/ozone/pull/64 it would be nice if we could replace the "16 skipped checks" with a single workflow that fetches the fork's overall CI status and propagates it. The current view makes it look like no tests ran, and does not provide a link to the CI result that actually matters when merging. That result is attached to the last commit which is less visible. Ethan On Wed, Oct 21, 2026 at 12:28 PM Attila Doroszlai <[email protected]> wrote: > Thanks Chi-Hsuan for the response. > > > > This will be _easier_ than before, since each commit carries its own > > > status, which is visible directly in the PR until hidden by the PR's > own > > > status. > > > > I might be missing something here, but I don't see the fork CI status on > > the PR. For example, the fork CI for #11663 passed, but the PR shows 0 > > checks and no status next to the commit. > > The workflow for #11663 was approved in the meantime, but I checked some > others > and can confirm: no status is visible. I guess that might happen because > the > pull_request trigger still exists, it just needs approval to start. > > I have created a POC pull request [5] in my fork, which removes all > pull_request > triggers. There the status from push run is visible. It would be great > if someone > without write access to apache/ozone could open a PR there for this > change, to test > what it looks like in that case. > > > I noticed that Spark [3] and Hadoop [4] already use a small workflow to > > report fork CI status on the PR. Perhaps we could adopt a similar > > lightweight approach in Ozone, assuming the additional runner usage is > > minimal? This would make it easier for reviewers to verify CI results > > without navigating to the fork. > > Sure, if the push status discussed above turns out to work only for > committers, > we can adopt one of those workflows sooner. If push status is visible in > the PR, > I don't see the need for such a workflow. > > > Another thing worth considering is whether the fork CI actually ran as > > expected. For example, the fork might have an outdated or modified > > workflow, or it might skip required checks. > > That's a good point. Currently the labeler adds "CI" label if the PR > changes any > workflows, checks or related files. We can make that label more prominent, > add a comment on the PR, or similar. > > > For PRs that really need additional validation, I think we could still > let > > committers manually trigger integration CI against the latest master > before > > merging. This could address the concern about changes to master after the > > fork CI passes, without running PR CI on every update. > > Committers can already do this by merging master into the PR branch, as > long as > the "Allow edits and access to secrets by maintainers" checkbox is > checked, which > is the default. Otherwise we can ask the author do the same. > > An "Update branch" button [6] can also be enabled for pull requests in > repository > settings available via .asf.yaml [7], which should make it even easier. I > have not > tried this yet, but see it in .asf.yaml of some other repos like Airflow > and Pulsar. > I assume the button would be visible to PR author and those with write > access. > > -Attila > > [5] https://github.com/adoroszlai/ozone/pull/64 > [6] > https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/keeping-your-pull-request-in-sync-with-the-base-branch#updating-your-pull-request-branch > [7] https://github.com/apache/infrastructure-asfyaml#pull-request-settings > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
