bug-gnulib
[Top][All Lists]
Advanced

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

Re: Initial Travis smoke testing


From: Bruno Haible
Subject: Re: Initial Travis smoke testing
Date: Sat, 28 Mar 2020 23:19:10 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-174-generic; KDE/5.18.0; x86_64; ; )

Hi Jeffrey,

> The initial Travis smoke test went in today. It is on my testing fork
> at https://github.com/noloader/gnulib.

I appreciate that you are going forward!

> The big TODO is, how to partition the list so every module is tested
> at least once a week or every two weeks.
> 
> Does anyone have an idea about partitioning the tests? (I have some,
> but I don't want to taint suggestions).

An idea could be as follows:

  - Fix a number N of test runs for which you are going to store the
    list of tested modules.
  - For a new test run:
    1. Take the set of all modules, minus the modules that were selected
       in the last N test runs.
    2. If this set is empty, print "N is too large", decrement N, and go
       to step 1.
    3. Otherwise select up to, say, 5 elements of this module set at random.
    4. Invoke './gnulib-tool --create-testdir --single-configure ...'
       with these module names.
    5. gnulib-tool prints the full list of modules. Store them in the
       list of tested modules.

This way, modules at the "top" of the dependency hierarchy will not
be tested frequently, but through step 1, a certain amount of redundancy
is avoided.

If this doesn't work because you can't store things between runs, I would
vote for some clever algorithm on the dependency graph.

Bruno




reply via email to

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