Improve GH Action PR assign + labeling

[carlisia]

Signed-off-by: Carlisia [email protected]

Please add a summary of your change

This change removes the synchronize parameter from the pull_request_target GH action in the Auto Assign PR Reviewers workflow. This should avoid the workflow from being triggered on all PR events, such as additional commits, which has the effect of adding additional reviewers (with each additional commit) beyond the current limit of 2. We only want this to be triggered when the PR opens, or when the PR changes from WIP to "ready for review".

It also separates the auto labeling GH action into the "Auto Label PRs" workflow. This one we want to be triggered on every event, so it keeps the synchronize and all other parameters the same.

Thanks to @zubron for pointing these out (in #3573 (comment)). Hopefully this will work.

Does your change fix a particular issue?

Fixes #(#3573)

PS: It doesn't completely fix the entire issue. For example: if the author wants to assign 2 specific reviewers before the PR is created, the GH action will still assign additional reviewers on the "open" event. This is the known bug in the action.

A way to get around this is to remove the originally assigned reviewers after the PR is created, and add the ones you want (assuming they don't match). This "works", but causes unnecessary notifications for the soon-to-be-removed reviewers.

A way to get around wanting to

Please indicate you've done the following:

• Accepted the DCO. Commits without the DCO will delay acceptance.
• Created a changelog file or added /kind changelog-not-required.
• Updated the corresponding documentation in site/content/docs/main.

[carlisia]

Changing this to draft. Let me do some tests on a personal repo. It seems that w/o the synchronize param events such as additional commits will cause the GH action to fail bc there's an existing process but no event to handle it. This makes sense now that I think about it.

[carlisia]

I tested this and it works as expected. Turns out, when on: pull_request_target is used, which is what we have with this action, additional events are not expected to have the synchronize event type to handle them, so it silently does not trigger any processing. on: pull_request, on the other hand, will complain if there isn't the synchronize type to handle additional events.

This is ready for review.

[zubron]

Thanks!