Hi,
> I also think that approach #1 is simpler and saner, but thinking about
> where we're going with the test runner development, I started to have
> doubts about it. The reason is that we're adding parallel and multi
> environment (process, machine, container) execution capabilities to the
>
On Thu, May 09, 2019 at 06:40:40AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Tests can also timeout due to slow downloads of test kernels.
> > > Any chance to run the downloads without timeout?
> >
> > I acknowledge this is an issue, and have thought about two possible
> > ways to solve it:
> >
Hi,
> > Tests can also timeout due to slow downloads of test kernels.
> > Any chance to run the downloads without timeout?
>
> I acknowledge this is an issue, and have thought about two possible
> ways to solve it:
>
> 1) Downloading/caching/checking all the test assets in a job "pre-tests"
>
On Wed, May 08, 2019 at 12:28:24PM +0200, Gerd Hoffmann wrote:
> On Thu, May 02, 2019 at 09:41:21PM -0300, Eduardo Habkost wrote:
> > From: Cleber Rosa
> >
> > When running on very low powered environments, some tests may time out
> > causing false negatives. As a conservative change, and for
>
On Thu, May 02, 2019 at 09:41:21PM -0300, Eduardo Habkost wrote:
> From: Cleber Rosa
>
> When running on very low powered environments, some tests may time out
> causing false negatives. As a conservative change, and for
> considering that human time (investigating false negatives) is worth
> mo
From: Cleber Rosa
When running on very low powered environments, some tests may time out
causing false negatives. As a conservative change, and for
considering that human time (investigating false negatives) is worth
more than some extra machine cycles (and time), let's increase the
overall time
