| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
This isn't particularly accurate, what's actually being stored is the current
time when the record is inserted in to the coordinator database, but that
should happen just before the agent starts the build, so hopefully that's good
enough.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
To use with the derivation ordered allocator.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is important to speed up looking for derivations that provide an output,
that's used in the allocation process.
|
| |
|
|
|
|
| |
This will hopefully make it easier to create narinfo files for the outputs. I
think all of this information can be derived from the nar, but I'm not sure
how to do that, so maybe this can eventually be removed.
|
| |
|
|
|
|
|
| |
This is when a build was allocated to an agent, but the agent couldn't setup
the environment for the build. One failure I'm particularly thinking about is
where inputs to the derivation are missing, so add another table to store
them.
|
| | |
|
| |
|
|
|
|
|
| |
One table to store which build is allocated to which agent, and another to
store a "plan" of allocations. For this plan, a build can be potentially
allocated to multiple agents, and which agent it will be allocated to depends
on which agent claims it first.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|