[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) |
Hi,
Simon Tournier <zimon.toutoune@gmail.com> writes:
> Hi Maxim,
>
> On Thu, 09 Nov 2023 at 10:04, Maxim Cournoyer <maxim.cournoyer@gmail.com>
> 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.
--
Thanks,
Maxim
- Re: Turning off tests leads to a different store item, (continued)
- Re: Turning off tests leads to a different store item, Felix Lechner, 2023/11/07
- Re: Turning off tests leads to a different store item, Maxim Cournoyer, 2023/11/08
- Re: Turning off tests leads to a different store item, Felix Lechner, 2023/11/08
- Re: Turning off tests leads to a different store item, Vagrant Cascadian, 2023/11/08
- Re: Turning off tests leads to a different store item, Saku Laesvuori, 2023/11/08
- Re: Turning off tests leads to a different store item, Simon Tournier, 2023/11/08
- Re: Turning off tests leads to a different store item, Maxim Cournoyer, 2023/11/08
- Re: Turning off tests leads to a different store item, Simon Tournier, 2023/11/09
- Re: Turning off tests leads to a different store item, Maxim Cournoyer, 2023/11/09
- Re: Turning off tests leads to a different store item, Simon Tournier, 2023/11/16
- Re: Turning off tests leads to a different store item,
Maxim Cournoyer <=