From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:46632) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3HqF-0002Mc-AA for guix-patches@gnu.org; Sun, 16 Feb 2020 06:12:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3HqE-0005Ce-5D for guix-patches@gnu.org; Sun, 16 Feb 2020 06:12:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:59011) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j3HqE-0005CT-1v for guix-patches@gnu.org; Sun, 16 Feb 2020 06:12:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j3HqD-0004KX-Tx for guix-patches@gnu.org; Sun, 16 Feb 2020 06:12:01 -0500 Subject: [bug#37305] Making system installation tests faster Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87sgpby4p9.fsf@gmail.com> <87y2yg3t3s.fsf@gnu.org> <87k14sfaz7.fsf@gmail.com> <87lfp6b5cs.fsf_-_@gmail.com> <8736bdf5il.fsf@gnu.org> <87blpzozz7.fsf@gmail.com> Date: Sun, 16 Feb 2020 12:11:47 +0100 In-Reply-To: <87blpzozz7.fsf@gmail.com> (Maxim Cournoyer's message of "Sun, 16 Feb 2020 00:36:28 -0500") Message-ID: <8736ba3hxo.fsf_-_@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Maxim Cournoyer Cc: 37305@debbugs.gnu.org Hi Maxim, Maxim Cournoyer skribis: > Ludovic Court=C3=A8s writes: > >> Hi Maxim! >> >> Great to see Btrfs support improving; many people will love that! >> >> Maxim Cournoyer skribis: >> >>> From 3640bea548826e1c1ec9b766da1fdfe4791d7452 Mon Sep 17 00:00:00 2001 >>> From: Maxim Cournoyer >>> Date: Sun, 17 Nov 2019 06:01:00 +0900 >>> Subject: [PATCH 1/9] gnu: tests: Reduce the time required to run the sy= stem >>> 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 pro= cedure. >>> * build-aux/run-system-tests.scm (tests-for-channel-instance): Use it, = when >>> GUIX_DEV_HACKS is defined. >> >> I understand the need, but I=E2=80=99d really like to avoid that; it=E2= =80=99s too >> fragile IMO. >> >> But I have good news! First, commit >> 887fd835a7c90f720d36a211478012547feaead0 really improved things by >> avoiding the full =E2=80=98guix=E2=80=99 package rebuild (and we=E2=80= =99re 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=E2=80=99s still room for improvement, but I=E2=80=99d 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=E2=80=99s grabbing files from the working tree, with heuristics to minim= ize the changes in incorporating files that shouldn=E2=80=99t be there; I think= it=E2=80=99s 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 implement= ation 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=E2=80=99d have to maintain that in the meantime and de= al with any =E2=80=9Csurprising=E2=80=9D effects it has for those using it. FWIW, when testing (gnu installer tests), I only have to rebuild =E2=80=9Cguix-system-tests.drv=E2=80=9D, 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=E2=80=99s not necessary to have = the current =E2=80=98guix=E2=80=99 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=E2=80=99.