vriska/hydra
0
0
Fork 0
forked from lix-project/hydra
Code Pull requests Activity

Do not copy for both stores for now

Browse source 
It has a performance cost, and as the comment says we should be doing
the better solution. We want to land this preparatory change on prod
while the rest is still on staging, so we should just skip it for now.

Skipping it will not affect regular fixed-output and input-addressed
derivations, which are the only ones prod would deal with upon getting
this code.

The main CA derivations support branch will revert this commit so it
still works.
This commit is contained in:
John Ericson 2023-12-07 15:05:03 -05:00
parent 31ea6458ca
commit 2ee0068fdc
1 changed files with 1 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
src/hydra-queue-runner/build-remote.cc
View file

@ -425,20 +425,6 @@ static void copyPathFromRemote(
const ValidPathInfo & info
)
{
// Why both stores? @thufschmitt says:
//
// > I think it's an easy (and terribly inefficient 😬) way of
// making sure that `localStore.queryRealisations` will succeed
// (which we IIRC we need later to get back some metadata about the
// path to put it in the db).
// >
// > To be honest, we shouldn't do that but instead carry the needed
// metadata in memory until the point where we need it (but that can
// come later once we're confident that this is at least correct)
//
// TODO make the above change to avoid copying excess data back and
// forth.
for (auto * store : {&destStore, &localStore}) {
/* Receive the NAR from the remote and add it to the
destination store. Meanwhile, extract all the info from the
NAR that getBuildOutput() needs. */
@ -458,8 +444,7 @@ static void copyPathFromRemote(
extractNarData(tee, localStore.printStorePath(info.path), narMembers);
});
store->addToStore(info, *source2, NoRepair, NoCheckSigs);
}
destStore.addToStore(info, *source2, NoRepair, NoCheckSigs);
}
static void copyPathsFromRemote(