GNU bug report logs - #27876
[PATCH] cuirass: add Hydra compatible HTTP API.

Previous Next

Package: guix-patches;

Reported by: Mathieu Othacehe <m.othacehe <at> gmail.com>

Date: Sun, 30 Jul 2017 10:09:01 UTC

Severity: normal

Tags: patch

Done: Mathieu Othacehe <m.othacehe <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #49 received at 27876-done <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 27876-done <at> debbugs.gnu.org
Subject: Re: [bug#27876] [PATCH v2 1/3] cuirass: Store new information in
 database to prepare new HTTP API integration.
Date: Sun, 10 Sep 2017 15:26:44 +0200
Hi Ludo,

> Basically, between two subsequent evaluations, 99% of the derivations
> are exactly the same (assuming an evaluation is triggered at each git
> push, and each git push adds/modifies just a handful of packages).  If
> we record new builds for these 99%, even though nothing has changed,
> then that’s potentially bad, no?

Hmm, you're right but the situation is already problematic.

On each evaluation, N new entries will appear in Derivations table
(because the primary key is on derivation,evaluation tuple).

N new entries will also appear in Builds table (both with primary key on
id or on derivation,evaluation,output tuple).

When build start/stop will be detected, only a small part of N
(derivations which were rebuilt), will be added to Builds. Checking for
pre-existing builds with the same derivation will become useless unless
I'm wrong.

So there's still the problem of Derivations table growing from N at each
commit. I'm not sure what to do about it. Maybe removing the
"evaluation" field, and puting primary key on "derivation" only would be
better ?

Thanks,

Mathieu




This bug report was last modified 7 years and 259 days ago.

Previous Next


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