The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions.
Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay.
I want to solve this by using the PullRequestPoller for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with an expiration time. The poller has this functionality built in already with the retry with a date feature.
While doing this, I also want to re-evaluate some of the expire times that are being set currently.
Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay.
I want to solve this by using the PullRequestPoller for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with an expiration time. The poller has this functionality built in already with the retry with a date feature.
While doing this, I also want to re-evaluate some of the expire times that are being set currently.
- duplicates
-
SKARA-1572 Improve TestInfoBot scheduling
- Closed
- relates to
-
SKARA-1678 Missed calling lastBatchHandled in TestInfoBot
- Resolved