[bug#27876] [PATCH v2 1/3] cuirass: Store new information in database to prepare new HTTP API integration.

[ludo@gnu.org (Ludovic Courtès)]

Howdy,

Mathieu Othacehe <m.othacehe@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’.