Bug 201924 - EWS should terminate an ongoing job as soon as a patch/hash becomes obsolete
Summary: EWS should terminate an ongoing job as soon as a patch/hash becomes obsolete
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Aakash Jain
URL:
Keywords: InRadar
: 217964 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-09-18 11:32 PDT by Aakash Jain
Modified: 2024-03-12 11:55 PDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aakash Jain 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.
Comment 1 Aakash Jain 2019-09-18 11:32:26 PDT
<rdar://problem/27768813>
Comment 2 Radar WebKit Bug Importer 2019-09-18 11:32:46 PDT
<rdar://problem/55486159>
Comment 3 Aakash Jain 2020-10-20 10:01:24 PDT
*** Bug 217964 has been marked as a duplicate of this bug. ***
Comment 4 Aakash Jain 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.