Age | Commit message (Collapse) | Author | Files | Lines |
|
The storeUri variable in the build-remote hook is declared very much to
the start of the main function and a bunch of lines later, the same
variable gets checked via hasPrefix() but it gets assigned *after* that
check when the most suitable machine for the build was choosen.
So I guess this was just a typo in d16fd2497374671c92cb877f9570d65783a7
and what we really want is to either checkd the prefix *after* assigning
storeUri or use bestMachine->storeUri directly.
I choose the latter, because the former could introduce even more
regressions if the try block where the variable gets assigned terminates
early.
Nevertheless, the reason why the log output didn't work is because
hasPrefix() checked for "ssh://" in front of storeUri, but if the
storeUri isn't set correctly (or at all), we don't get the log file
descriptor set up properly, leading to no log output.
I've adjusted the remote-builds test to include a regression test for
this, so that we can make sure we get a build output when using remote
builds.
In addition to that I've tested this with two of my build farms and the
build logs are emitted correctly again.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
You can now say '--store /tmp/nix' instead of '--store local?root=/tmp/nix'.
|
|
Fixes #1599.
|
|
E.g.
$ nix build nixpkgs.hello --builders 'root@wendy'
[1/0/1 built] building hello-2.10 on ssh://root@wendy: checking for minix/config.h... no
|
|
|
|
This makes the progress indicator show statuses like "connecting to
'root@machine'".
|
|
This ensures that command line flags such as --builders get passed
correctly.
|
|
Fixes the error
error: opening lock file '/nix/var/nix/current-load/main-lock': Permission denied
when using a chroot store.
|
|
|
|
Relevant RFC: NixOS/rfcs#4
$ ag -l | xargs sed -i -e "/\"/s/’/'/g;/\"/s/‘/'/g"
|
|
|
|
Functions like copyClosure() had 3 bool arguments, which creates a
severe risk of mixing up arguments.
Also, implement copyClosure() using copyPaths().
|
|
|
|
Opening an SSHStore or LegacySSHStore does not actually establish a
connection, so the try/catch block here did nothing. Added a
Store::connect() method to test whether a connection can be
established.
|
|
This is useful for one-off situations where you want to specify a
builder on the command line instead of having to mess with
nix.machines. E.g.
$ nix-build -A hello --argstr system x86_64-darwin \
--option builders 'root@macstadium1 x86_64-darwin'
will perform the specified build on "macstadium1".
It also removes the need for a separate nix.machines file since you
can specify builders in nix.conf directly. (In fact nix.machines is
yet another hack that predates the general nix.conf configuration
file, IIRC.)
Note: this option is supported by the daemon for trusted users. The
fact that this allows trusted users to specify paths to SSH keys to
which they don't normally have access is maybe a bit too much trust...
|
|
This allows hydra-queue-runner to use it.
|
|
|
|
The build hook mechanism expects build log output to go to file
descriptor 4, so do that.
|
|
This restores the old behaviour.
|
|
For backwards compatibility, if the URI is just a hostname, ssh://
(i.e. LegacySSHStore) is prepended automatically.
Also, all fields except the URI are now optional. For example, this is
a valid nix.machines file:
local?root=/tmp/nix
This is useful for testing the remote build machinery since you don't
have to mess around with ssh.
|
|
This is to simplify remote build configuration. These environment
variables predate nix.conf.
The build hook now has a sensible default (namely build-remote).
The current load is kept in the Nix state directory now.
|
|
Since build-remote uses buildDerivation() now, we don't need to copy
the .drv file anymore. This greatly reduces the set of input paths
copied to the remote side (e.g. from 392 to 51 store paths for GNU
hello on x86_64-darwin).
|
|
|
|
|
|
|
|
This is unnecessary because we make only one connection.
|
|
|
|
|
|
|
|
|
|
http://hydra.nixos.org/build/46805140
|
|
|
|
|
|
Tests fail currently because the database is not given proper hashes in the VM
|
|
|
|
|
|
handling
|
|
|