Add edited event action for some workflow trigger [skip ci]

[pxLi]

Signed-off-by: Peixin Li [email protected]

fix #6259

Add edited action for several github CIs, so that when people switch base ref, those CI could get triggered automatically. NOTE:

1. We target this to 22.10, so only branches later than 22.10 (include this commit) would take effect
2. this one does not include blossom-ci, people should still manually trigger it.

Verified in my forked repo, reopen https://github.com/pxLi/spark-rapids/actions/runs/2822585591 edited PR description (skipped) https://github.com/pxLi/spark-rapids/actions/runs/2822501330 edited BASE ref https://github.com/pxLi/spark-rapids/actions/runs/2822465324

[pxLi]

build

[pxLi]

cc @jlowe @gerashegalov I have tried the edited event, current setup could introduce some side effects if we edit the PR but not the base ref. The existing status will be override by the Skipped run, e.g. for PR does not require base ref change, if we edit the desc, then Successful CIs would be Skipped after editing.

I also tried to introduce reusing caller (workflow_call) (https://github.com/pxLi/spark-rapids/blob/7385521bf2164e1c72542889a10feb96ddcfb859/.github/workflows/caller.yml) to do the edit w/ base ref check, so it would not override the existing CI status if no base ref change. But the github status naming will be a separate one in case

comparing to original

which may confuse people. Also workflow_run could support upstream triggering but it only works on default branch and it would lose PR event payloads during triggering.

Not sure if you guys have some better ideas, or we think it's fine for us to have such side effects above

[jlowe]

Bummer, losing a prior CI status just for a headline change is really unfortunate. That may be worse, since changing headlines occurs more often than changing the PR base.

Thinking off the top of my head: Is it possible to have a separate workflow from normal CI that looks only for edited events where the base changes, and if that is detected, it requests a rerun of the normal CI workflows? Not sure if it's possible and is a roundabout approach, but essentially we want to act like someone manually re-kicked the normal CI workflows when the base branch changes.

[pxLi]

Bummer, losing a prior CI status just for a headline change is really unfortunate. That may be worse, since changing headlines occurs more often than changing the PR base.

Thinking off the top of my head: Is it possible to have a separate workflow from normal CI that looks only for edited events where the base changes, and if that is detected, it requests a rerun of the normal CI workflows? Not sure if it's possible and is a roundabout approach, but essentially we want to act like someone manually re-kicked the normal CI workflows when the base branch changes.

For now, I cannot find any simple solution from the official doc. But yeah, I think it should be possible if we write our own script or find some existing actions to leverage github API to trigger prior CI, I will do some research later when I have time

[pxLi]

I tried other event types like workflow_dispatch and repository_dispatch, but they only work for default branch and cannot update check status well for pull request.

I think there might be 2 options w/ a separate workflow (monitor base-ref-change trigger)

1. write some script to reuse related CI workflows inside base-ref-change workflow, and then do some customized status updates within base-ref-change workflow since the original PR check status update requires PR-related trigger (not dispatch trigger).
2. Pick a rare-used event type and add it to the existing workflows, then call API in the base-ref-change workflow to do the operation directly to the PR for triggering, so we could still get the check status from the original workflow. Like close + reopen or lock + unlock

For me, option 2 maybe simpler to implement and maintain, any opinions?

[gerashegalov]

For Option 1 we could instead of skipping have a reusable action:

1. retrieve the check run statuse for the current PR branch HEAD https://docs.github.com/en/rest/checks/runs#list-check-runs-for-a-git-reference
2. retrieve blossom-ci status https://docs.github.com/en/rest/commits/statuses#list-commit-statuses-for-a-reference

and make it outputs of the action

Then the blossom-ci and and other checks can check whether the prior status exists and if successful just log the link and exit with success, otherwise rerun the main logic

[pxLi]

For Option 1 we could instead of skipping have a reusable action:

1. retrieve the check run statuse for the current PR branch HEAD https://docs.github.com/en/rest/checks/runs#list-check-runs-for-a-git-reference
2. retrieve blossom-ci status https://docs.github.com/en/rest/commits/statuses#list-commit-statuses-for-a-reference

and make it outputs of the action

Then the blossom-ci and and other checks can check whether the prior status exists and if successful just log the link and exit with success, otherwise rerun the main logic

Sounds good to me. We may simply catch base-ref-change events from edited, then list check runs of current commit and try re-trigger.

For a reusable github action, we can get back in the future if needed.

[pxLi]

switch this one to 22.12, I will find some time to deal w/ it later

[pxLi]

close this one for now. We will reopen it when available