Hi, I don't think that 20 seconds will affect the overall process :). It will only become a problem if we increment the number of these kind of tests by *a lot*...

Another solution is to make some tests run in parallel. But for this to run properly we have to increase the number of slaves in Jenkins, and the bad news is that we reached the current maximum limit (of 5 slaves).

We have to talk to the inria people to see what solution they could provide to us for this, because otherwise the infrastructure does not scale for lots of PRs with big jobs.

Guille

On Fri, Sep 7, 2018 at 8:23 AM Alistair Grant <akgrant0710@gmail.com> wrote:

On Thu, 6 Sep 2018 at 23:06, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
>
>
> Maybe we could have a package with release tests that are not executed
> by the CI but that are executed at the moment of the feature freeze and
> some time before the Pharo release to ensure the quality of the code
> base for tests that are too long?

The drawback of this approach is that it relies on the original author
going back and submitting a fix in a timely manner (quite possibly
after they've moved on to other things).

If the tests could be run on a specified set of classes / methods,
perhaps we could run them as part of Iceberg, i.e. when going to
commit code, these tests are run on the classes in the commit and a
warning opened prompting the user to fix them before actually
committing.

Cheers,
Alistair

��	Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: +33 06 52 70 66 13