GNU bug report logs - #24496
offloading should fall back to local build after n tries

Previous Next

Full log

Message #17 received at 24496 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 24496 <at> debbugs.gnu.org, ng0 <ngillmann <at> runbox.com>
Subject: Re: bug#24496: offloading should fall back to local build after n
 tries
Date: Thu, 16 Dec 2021 13:52:14 +0100

Hi,

I am just hitting this old bug#24496 [1].

On Mon, 26 Sep 2016 at 18:20, ludo <at> gnu.org (Ludovic Courtès) wrote:
> ng0 <ngillmann <at> runbox.com> skribis:
>
>> When I forgot that my build machine is offline and I did not pass
>> --no-build-hook, the offloading keeps trying forever until I had to
>> cancel the build, boot the build-machine and started the build again.

[...]

> Like you say, on Hydra-style setup this could be a problem: the
> front-end machine may have --max-jobs=0, meaning that it cannot perform
> builds on its own.
>
> So I guess we would need a command-line option to select a different
> behavior.  I’m not sure how to do that because ‘guix offload’ is
> “hidden” behind ‘guix-daemon’, so there’s no obvious place for such an
> option.

When the build machine used to offload is offline and the master daemon
is --max-jobs=0, I expect X tries (leading to timeout) and then just
fails with a hint, where X is defined by user.  WDYT?


> In the meantime, you could also hack up your machines.scm: it would
> return a list where unreachable machines have been filtered out.

Maybe, this could be done by “guix offload”.


Cheers,
simon


1: <http://issues.guix.gnu.org/issue/24496>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.