[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Turning off tests leads to a different store item

From: Maxim Cournoyer
Subject: Re: Turning off tests leads to a different store item
Date: Fri, 17 Nov 2023 23:38:40 -0500
User-agent: Gnus/5.13 (Gnus v5.13)


Simon Tournier <> writes:

> Hi Maxim,
> On Thu, 09 Nov 2023 at 10:04, Maxim Cournoyer <> 
> wrote:
>>> I agree.  On a side note, one of the issue is the time of some tests.
>>> Sometimes, packaging is frustrating: build takes ages, then you fix some
>>> tests, think it will be good, re-launch “guix build”, another test
>>> failing, repeat.  It could nice to be able to cache the result of the
>>> build phase.
>> I usually end up working in the /tmp/guix-build-* failed build of a
>> package for these situations; then I don't need to rebuild the whole
>> thing for each test suite run, and can test changes directly without
>> proper patches while working toward a fix.
> Do you know all the command lines equivalent for each phase run by all
> the build systems? ;-)

It depends of the build system, but for gnu-build-system, it's typically
just sourcing environment-variables then running 'make check', I think.
Note that 'live' environment variables are captured in the
'environment-variables' file, which is handy.

> Well, this workflow seems appealing but it never works for me on
> concrete situations.  Most of the time, my issue does not come from
> “what to do from command line” but “how to do it inside the Guix
> recipe”.
> For example, this test suite adjustment:
>           (add-before 'install 'disable-network-tests
>             (lambda _
>               (substitute* "test/runtests.jl"
>                 (("\"async.jl") "# \"async.jl")
>                 (("\"client.jl") "# \"client.jl"))

>                 (("@testset.*Set-Cookie casing.*" all)
>                  (string-append all "return\n"))))))))
> To have the correct replacement rules, I almost never get it right at
> the very first try, and the feedback loop is poor.  In some case, the
> replacement is done after 'unpack, so I can just kill the build process
> and check inside /tmp/guix-build-* if the output is the expected one.

I've used 'guix repl' in a failed build before, running the same
commands directly in the tree to observe their effects (e.g.,
substitutions) directly.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]