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

Previous Next

Full log

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
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 22:38:59 +0200

Howdy,

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

>> 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 ?

You’re right, I don’t know off the top of my head.  Perhaps we should
check the schemas that Hydra uses, it should be similar.

Future work!

Ludo’.

Previous Next

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