ASSIGNED 201924
EWS should terminate an ongoing job as soon as a patch/hash becomes obsolete 
https://bugs.webkit.org/show_bug.cgi?id=201924
Summary EWS should terminate an ongoing job as soon as a patch/hash becomes obsolete
Aakash Jain
Reported 2019-09-18 11:32:20 PDT
Most of the time, it's wasteful for EWS bots to keep building or testing once a patch has been obsoleted. It would be much better to drop obsoleted patches quickly, and to move to ones that people are actually waiting for. One exception is landed patches, where it's nice to know what EWS was going to come up with.
Attachments
Add attachment proposed patch, testcase, etc.
Aakash Jain
Comment 1 2019-09-18 11:32:26 PDT
<rdar://problem/27768813>
Radar WebKit Bug Importer
Comment 2 2019-09-18 11:32:46 PDT
<rdar://problem/55486159>
Aakash Jain
Comment 3 2020-10-20 10:01:24 PDT
*** Bug 217964 has been marked as a duplicate of this bug. ***
Aakash Jain
Comment 4 2024-03-12 11:55:27 PDT
Note that we added more checks for change being still active in https://bugs.webkit.org/show_bug.cgi?id=160739 and https://bugs.webkit.org/show_bug.cgi?id=203756 However, this bug is about proactively cancelling the ongoing builds. On a PR when a new hash is uploaded, actively go and check for previous hashes on that PR, check for the ongoing builds for those hashes and cancel them (using buildbot API). There might be multiple ways to implement the same. One approach can be to implement it in ews-app (since it already has information of all the hashes for a PR, and all the ongoing builds). In this approach, one of the main task would be to perform authentication to buildbot while calling the api. Another approach can be to implement this in buildbot configuration itself (inside events.py), whenever a new hash information comes, maybe ask ews-app for previous hashes on that PR, and ongoing builds for those PRs and then cancel them.
Note You need to log in before you can comment on or make changes to this bug.