Make it easier to find builds we may want to cancel
I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples:
- Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest.
- A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific.
- Only documentation files have changed. Building these on one platform should be sufficient.
- A differential was closed by a commit. Only the most recent build will be useful, if that.
It would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Trac & Git |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |
Activity
changed milestone to %8.4.1
added Tfeature request Trac import infrastructure labels
Is that a problem worth investing manpower in, instead of throwing computing power at it?
Also,
Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest.
whether only the most recent version is of interest is something that we may only know later.
Replying to [ticket:13240#comment:131628 nomeata]:
Is that a problem worth investing manpower in, instead of throwing computing power at it?
Also,
Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest.
whether only the most recent version is of interest is something that we may only know later.
Yes, we would prefer to throw more computing power in, but we don't have it. And yes, it's true that there can be surprisingly interesting features in just about any build. If we had sufficient build resources, we would certainly want to run them all so we could catch those gems. But in reality our build resources are extremely limited; we have to decide between letting things pile up over the course of the day, hoping that they'll be cleared up overnight, and losing some potentially useful information.
I implemented a simple web dashboard which shows when situations 1. and 2. are occurring. The question now is whether this should be hosted somewhere or if anyone other than me would use it.
Red = 1 Orange = 2
The code is also not very pretty and I am not too keen to tidy it up so I might just manage this myself.
changed milestone to %8.6.1
added Pnormal label
