Serialize try and non-try jobs

[Ms2ger]

I think running those in parallel might be what's causing homu to get confused.

[Manishearth]

I think the confusion wasn't due to this; it was because homu got restarted just at the same time it got some build results from buildbot, tainting its status forever in the build db.

(I tried to fix this by manipulating the pulls db, I should have tweaked the build db instead)

[KiChjang]

How does this "restart" happen? Is it a normal workflow that homu goes through, or is it due to user interaction?

[Manishearth]

User interaction. When pulling in a new config or something

[KiChjang]

So in other words, whenever we pull a new config, we'll have to make sure the following happens:

• Stop any builds that are current
• Comment on the PR related to the build about the stoppage
• Update the build database
• Pull in the new config
• Resume and message all outstanding builds

[Manishearth]

Well, usually I try to update the configs when there are no builds, or when there's no chance of a build notification, in case something like this happens.

It's a bit hard to stop current builds since homu will just go on to the next one.

[metajack]

I've asked @barosl for a feature to pause homu several times. Maybe someday we'll get that. For now you pretty much need to stop the service to stop it progressing builds, but then all the build notifications are dropped on the floor.

[Manishearth]

I've never looked at the homu code around this, but I probably could implement it; doesn't sound hard. If we're adding this might as well also add a treeclosed state which closes the tree for everything with p<10000 or something (for rustups and stuff)

[edunham]

Closing this in favor of servo/homu#129 because it wasn't actually a Try problem