| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
To avoid an additional store connection.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This probably isn't the main problem with having too many open files, but it
might help avoid bursts of open files.
|
| | |
|
| |
|
|
|
|
|
| |
Previously it would always connect to the store and substitute the derivation
if necessary. Now it checks first to see if there are some references from the
outputs that aren't from the inputs, and if that's the case, it goes on to
check if these are source files that need publishing.
|
| |
|
|
| |
As this can block if the store GC is running.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
To the build-success-publish-hook.
This should make it possible to pass all nars and narinfo's to the nar-herder
in one go, which in turn should make it possible to have the nar-herder
validate referential integrity, even in the case where one build has multiple
outputs which have circular references.
|
| | |
|
| |
|
|
|
| |
Build outputs can reference derivation source files. This change to the
publish hook enables publishing these referenced source files.
|
| | |
|
| |
|
|
|
|
| |
This will enable it to join builds to derivations, even if it doesn't know
about the derivation being built, since it'll be able to match the outputs
with other derivations it knows about.
|
| |
|
|
|
|
| |
This means that when using the nar-herder, you can get it to check for the
presence of the nar in the database, rather than relying on the narinfo on the
disk.
|
| | |
|
| |
|
|
|
|
|
|
| |
Now a procedure can be passed in, which should return arguments for the builds
to submit.
I'm looking at using this to spread retries across a range of machines for
example, by specifying different tags for each of the retries.
|
| |
|
|
|
| |
This should make it possible to check properly whether the outputs are needed,
instead of just assuming they are not if there's been a successful build.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Agents can skip submitting outputs where those outputs have already been
received, this saves some work when all the information is communicated in the
build status.
The publish hook worked with this change, because it checks for narinfo files,
and would not bother about the missing outputs if the corresponding narinfo
existed. This didn't quite work with the s3 publish hook though, but these
changes address that by getting the two hooks to write and check for narinfo
files in the same location.
|
| |
|
|
| |
As this probably makes sense to do.
|
| |
|
|
| |
My refactoring went quite wrong.
|
| |
|
|
|
|
| |
Don't include canceled builds in the build-for-derivation-exists? or
build-for-output-already-exists? options. I think it makes sense to not
include canceled builds in these options.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
As is used in the S3 publish hook. This is useful when you don't want to
overwrite existing nar+narinfo entries.
|
| |
|
|
| |
I've seen this happen with derivation source files.
|
| |
|
|
|
|
| |
This is useful when using tags to track the origin of builds. This doesn't
necessarily have to be mandatory, maybe there are some tags where propagating
isn't helpful.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Substitutes could be available for all direct inputs, but be missing for
things they reference. This could happen if those builds happened on a machine
with the store items available for example.
Therefore, search the entire graph for the relevant derivation when looking
for the derivation to build to provide the missing input.
This change matches up with the similar improvement around handling fetching
substitutes.
|
| |
|
|
| |
So that an absolute filename can be used.
|
| |
|
|
|
|
| |
So that it'll run only if the narinfo on S3 is changed, because this should
prevent it running when the hook wouldn't change the narinfo on S3, because
one already exists.
|
| |
|
|
| |
To allow doing things with the nar/narinfo files before they're deleted.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Plus more coordinator methods. This is a step towards making the allocator
configurable.
|
| |
|
|
|
|
| |
This is helpful if you don't have local storage for nars. There's nothing
special about S3 beyond it's something I wanted to be able to use. I'm hoping
to support other useful ways of publishing substitutes as well.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
|
|
This allows configurable code to be executed when builds succeed or fail.
|