[bug#37305] Making system installation tests faster

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>
>> Hi Maxim!
>>
>> Great to see Btrfs support improving; many people will love that!
>>
>> Maxim Cournoyer <address@hidden> skribis:
>>
>>> From 3640bea548826e1c1ec9b766da1fdfe4791d7452 Mon Sep 17 00:00:00 2001
>>> From: Maxim Cournoyer <address@hidden>
>>> Date: Sun, 17 Nov 2019 06:01:00 +0900
>>> Subject: [PATCH 1/9] gnu: tests: Reduce the time required to run the system
>>>  tests.
>>>
>>> When setting the GUIX_DEV_HACKS environment variable, the Guix package used
>>> inside the instrumented VMs recycles the binaries already found in the Guix
>>> checkout of the developer instead of rebuilding Guix from scratch.  This
>>> brings the time required for this component from 20+ minutes down to 2-3
>>> minutes on an X200 machine.
>>>
>>> * gnu/packages/package-management.scm (current-guix/pre-built): New 
>>> procedure.
>>> * build-aux/run-system-tests.scm (tests-for-channel-instance): Use it, when
>>> GUIX_DEV_HACKS is defined.
>>
>> I understand the need, but I’d really like to avoid that; it’s too
>> fragile IMO.
>>
>> But I have good news!  First, commit
>> 887fd835a7c90f720d36a211478012547feaead0 really improved things by
>> avoiding the full ‘guix’ package rebuild (and we’re only talking about
>> the installation tests; other tests are just fine.)  Second, there are
>> improvements to Guile that will appear in 3.0.1/2.2.7 that make
>> compilation of big files roughly twice as fast.
>>
>> There’s still room for improvement, but I’d rather work in those
>> directions.  WDYT?
>
> With a little bit more love (inheriting from the Guix package from the
> inferior captured at build time), I don't see the hack being any less
> fragile than the Guix checkout compiled and ran with ./pre-inst-env.

It’s grabbing files from the working tree, with heuristics to minimize
the changes in incorporating files that shouldn’t be there; I think it’s
fragile.  :-)

It also breaks that idea that things compiled by Guix are well under
control.

> There's no arguing that it *is* a hack, but:
>
> 1) Being labeled as such (GUIX_DEV_HACKS)
> 2) Being undocumented
> 3) Only being enabled explicitly (through that GUIX_DEV_HACKS
> environment variable)
> 4) Can be reverted easily in the future when the default, clean 
> implementation is
> fast enough to obsolete it.
>
> To me means its targeted to developers who understand the nature of the
> hack and is provided without any warranty.
>
> And while it's exciting that Guile's compilation time is going to be
> improved, no compiler's going to be as efficient as "no compilation"
> ;-).

True!  But still, we’d have to maintain that in the meantime and deal
with any “surprising” effects it has for those using it.

FWIW, when testing (gnu installer tests), I only have to rebuild
“guix-system-tests.drv”, which is fast.  And in fact, I can also not
rebuild anything by doing:

  (define operating-system-with-current-guix identity)

because in this particular case, I know it’s not necessary to have the
current ‘guix’ package.

I suppose this would also be an option in your case, when testing the
Btrfs changes, no?

Perhaps we should make this case more easily accessible through an
environment variable?

Thanks,
Ludo’.