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]
