Also animate color so that a transition from one notification to another
will appear more smoothly.
Promoted all members of defaultOptions.* up the dot to make core more
terse.
This came out of the conversation with Nicolas.
When QueueTaskDispatcher vetos the assignment, a buildable item might
stay buildable and unexecuted. Ane he found that it doesn't get retried,
despite the MaintainTask class that attempts to do so.
The issue is that the maintain() method actually doesn't try to assign
buildable tasks to executors. That happens inside the pop() method.
I think this goes against the original design of the maintain() method,
which is a giant synchronized block that moves all the relevant actors
from one state to another.
So I'm moving this code into the maintain method. In this way,
MaintainTask will automatically reattempt to assign buildable items
to executors, and scheduleMaintenance() and maintain() will really
do the same thing, and it solves the original problem.
The motivation of this is to enable test code to inject components from Jenkins, which means we need a single Injector that can see all of those, including @TestExtension and regular @Extension. Then I realized that the current implementation is broken, as it creates two independent Injectors. This has other undesirable side effects like @TestExtension components not being able to inject @Extensions, etc.
I briefly experimented with hierarchical Injectors (where we first create Injector that loads @Extension then create another that loads @TestExtension as a child), but this was hard to get right as we have no control over which ExtensionFinder gets instantiated first --- we'd be at the mercy of SezPoz.
So the eventual approach is to allow a single GuiceFinder to recognize multiple annotations. This also works well with our using child injector for installing plugins without restart
This reverts commit 47c520b13b.
I see it clearly now. I was bit concerned about double-counting,
because one expects that totalSnapshot (total # of executors)
includes idle executors. But this is not the case, and in any way
this code should be read as (x==0 && y==0 && z==0) not (x+y+z==0)
conceptually. So reverting my revert.
The needsSomeWhenNoneAtAll ought to take into account nodes which are coming online, especially when a cloud returns slaves which are not connected. This is fixed by adding the idleSnapshot, which takes connecting slaves into account (totalSnapshot does not).