Make "self-destructed" CQ slaves less confusing. |
|||
Issue descriptionThe CQ will abort remaining slaves and restart itself if it knows that waiting for those slaves to finish won't affect it's decisions to submit/not submit CLs. The phrase "self-destructed" confuses people. The links to build slave results on the waterfall confuse people, since you sometimes have 20 slaves aborted after a single slave failed with the real failure sorted randomly among the many slaves aborted. We should rename "self-destructed", and stop listing aborted slaves on the waterfall and on rejected CLs, or at least sort the real failures to the beginning of the list.
,
Jul 11
Makes sense.
,
Sep 24
This is still a relevant and confusing issue.
,
Sep 24
So does the "_ShutDownException" message in the "failed" stage really mean that the CQ decided to cancel the build? Then, yes, it would be extremely helpful if this were explained somewhere - if not in the waterfall tools then at least in the FAQ.
,
Sep 24
The current architecture makes it difficult to annotate this situation on the builds that get cancelled, but we could at least make it more clear on the master that it is cancelling builds. Currently it just logs e.g.: 06:48:05: INFO: Canceling buildbucket_ids: [u'8934507740160115920', u'8934507762772877872']
,
Sep 24
There have been UI improvements since this was filed, but further requests for improvement have been filed against those. Duping this against the newer bug, since it has more relevant context. |
|||
►
Sign in to add a comment |
|||
Comment 1 by bpastene@chromium.org
, Jul 11