The implementation can be summarized as the following:
It has a kill switch, so that we can safely redeploy the lambda just in case something went wrong. It also has a list of rollout_users (currently just zhouzhuojie) that are enabled as an allowlist and will only run the bot for this group at the beginning of the rollout.
If it's pull_request.* event, it will try to run the default dispatch logic, which adds a ciflow/default label and then signal with assign/unassign event to the main pytorch/pytorch repo.
If it's issue_comment.* event, it first checks if the comment has keyword @pytorchbot ciflow ..., if it does, apply the default dispatch logic and send signals.
Deployment note
[x] make sure the pytorchbot has the write permission of pull_request on pytorch/pytorch
[x] make sure the pytorchbot can listen to issue_comment events on pytorch/pytorch
[x] deploy with the ENABLE_CIFLOWBOT=false and monitor errors
[ ] deploy with the ENABLE_CIFLOWBOT=true and monitor errors (revert if something is wrong, finger crossed)
Stack from ghstack:
Implementation logic
The implementation can be summarized as the following:
It has a kill switch, so that we can safely redeploy the lambda just in case something went wrong. It also has a list of
rollout_users (currently just zhouzhuojie)
that are enabled as an allowlist and will only run the bot for this group at the beginning of the rollout.We are going to handle the following events.
If it's
pull_request.*
event, it will try to run the default dispatch logic, which adds aciflow/default
label and then signal withassign/unassign
event to the main pytorch/pytorch repo.If it's
issue_comment.*
event, it first checks if the comment has keyword@pytorchbot ciflow ...
, if it does, apply the default dispatch logic and send signals.Deployment note
pull_request
on pytorch/pytorchissue_comment
events on pytorch/pytorchENABLE_CIFLOWBOT=false
and monitor errorsENABLE_CIFLOWBOT=true
and monitor errors (revert if something is wrong, finger crossed)