| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
Use a temporary table to avoid computing the priorities for all builds. This
speeds up the allocation to only take a few seconds on the database I'm
testing against.
|
| |
|
|
| |
In the agent and allocator.
|
| |
|
|
|
|
| |
For the derivation ordered allocator. This is an quick alternative for having
some kind of archival mechanism for builds. It should reduce the time it takes
the allocator to run.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
To try and avoid the data from the two queries being inconsistent.
|
| |
|
|
|
| |
This might help avoid any issue with having a unprocessed build, but not
knowing the priority, as it's just been processed.
|
| | |
|
| |
|
|
|
| |
Use EXCEPT, rather than NOT IN to make the SQL query faster. Also, just return
and use the build id, rather than a alist.
|
| |
|
|
|
|
|
| |
It worked under some database conditions, but was very slow under others. Move
more of the logic in to SQL in an attempt to make the allocator faster. This
sort of works, but there were some advantages to the approach before the
approach being replaced in this commit.
|
| | |
|
| |
|
|
|
| |
Previously it was ignoring outputs without builds or build results. This fixes
that.
|
| |
|
|
| |
By using a bigger SQL query, rather than lots of small ones.
|
| |
|
|
| |
Because it's building everything, missing inputs shouldn't be as relevant.
|
| |
|
|
|
| |
This should work better where the build coordinator is being used to build all
derivations in the graph.
|
| |
|
|
|
| |
Previously it was ignoring all setup failures when a single one of the outputs
for a single setup failure should be available.
|
| |
|
|
|
|
| |
As well as sorting by priority, this now looks at which builds are missing
outputs, and which builds will provide those outputs and tries to order the
builds providing the outputs before the builds that need them.
|
| |
|
|
|
|
|
|
|
| |
This should at least do a better job of boosting the priority of builds
required to perform builds which have high priorities.
I'm expecting this to result in contiguous chunks of builds with all the same
priority, and the ordering within those chunks isn't yet decided
intelligently.
|
| |
|
|
| |
As it's not dependent on the agent.
|
| |
|
|
| |
This is called for the same outputs multiple times, so memoize the result.
|
| | |
|
| |
|
|
| |
This will probably perform better when there are lots of step failures.
|
| |
|
|
|
| |
As the allocator is so slow at the moment, that agents are running out of
work.
|
| |
|
|
| |
This helps to avoid planning too far ahead. This should be configurable.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
That submits new build jobs to build these missing inputs if appropriate.
This means that you can tell the coordinator to build something, and it will
automatically attempt to build the dependencies if they're missing.
|
|
|
Move some of the code around, and trigger allocating builds via a thread if an
agent fails to setup for a build and when a build succeeds/fails.
This is important, as some setup failures can be handled by the build
allocator, for example a build finishing may unblock other builds waiting for
outputs it generates.
|