parallelExecution in sbt 0.9.x

[ijuma]

Hi,

I was looking for the equivalent of parallelExecution in SBT 0.9.x and could not find it. Does it still exist? If not, will it be reintroduced before 0.10?

I am asking because I have some projects that contain integration tests that use a substantial amount of memory. As such, it's useful to restrict the number of tests that are executed simultaneously to avoid OOMs, swapping and so on. In SBT 0.7.x, I could override parallelExecution to achieve this (although a more fine-grained approach would be even better).

Best,

Ismael

[Mark Harrah]

There isn't an equivalent configuration, but it is reasonable that there should be before 0.10.0. If you could open a bug report, I'll at least add the ability to turn it off entirely, but I think I can make it configurable for a single 'test' command. That is, all of the integration tests for a particular project could be declared as running in a single thread.

I would indeed like a more fine-grained approach that perhaps specifies which tasks must not run concurrently with each other, must not run concurrently with anything, etc... That is post-0.10 though.

-Mark

[ijuma]

On Saturday, 21 May 2011 16:51:32 UTC+1, Mark Harrah wrote:

There isn't an equivalent configuration, but it is reasonable that there should be before 0.10.0.  If you could open a bug report, I'll at least add the ability to turn it off entirely, but I think I can make it configurable for a single 'test' command.  That is, all of the integration tests for a particular project could be declared as running in a single thread.

Filed here https://github.com/harrah/xsbt/issues/22 . The former would be good enough for me, but the latter would be excellent. :) 

I would indeed like a more fine-grained approach that perhaps specifies which tasks must not run concurrently with each other, must not run concurrently with anything, etc...  That is post-0.10 though.

Makes sense.

Best,

Ismael

[Mark Harrah]

On Sat, 21 May 2011 09:21:16 -0700 (PDT)
ijuma <ism...@juma.me.uk> wrote:

> On Saturday, 21 May 2011 16:51:32 UTC+1, Mark Harrah wrote:
> >
> > There isn't an equivalent configuration, but it is reasonable that there
> > should be before 0.10.0. If you could open a bug report, I'll at least add
> > the ability to turn it off entirely, but I think I can make it configurable
> > for a single 'test' command. That is, all of the integration tests for a
> > particular project could be declared as running in a single thread.
> >
> Filed here https://github.com/harrah/xsbt/issues/22 . The former would be
> good enough for me, but the latter would be excellent. :)

To disable parallel execution for the whole build:

parallelExecution in Global := false

To ensure tests in the current project are run serially, while allowing everything else to run in parallel (including tests in other projects):

parallelExecution in Test := false

Somewhat related, sbt makes it rather easy to add a new test configuration. In your case, you can put your integration tests in a different configuration and still get unit tests in parallel.

lazy val root = Project(...)
.configs( IntegrationTest )
.settings( Defaults.itSettings : _*)
.settings( parallelExecution in IntegrationTest := false)

Integration test sources would go in src/it/scala.

If you wanted a custom test configuration:

lazy val FunTest = config("fun") extend(Test)
lazy val root = Project(...)
.configs( FunTest )
.settings( inConfig(FunTest)(Defaults.testSettings) : _*)
.settings( parallelExecution in FunTest := false)

Test sources would go in src/fun/scala.

-Mark

[ijuma]

On Saturday, 21 May 2011 19:13:15 UTC+1, Mark Harrah wrote:

To disable parallel execution for the whole build:

 parallelExecution in Global := false

To ensure tests in the current project are run serially, while allowing everything else to run in parallel (including tests in other projects):

 parallelExecution in Test := false

Thanks for adding this so quickly. :) 

Somewhat related, sbt makes it rather easy to add a new test configuration.  In your case, you can put your integration tests in a different configuration and still get unit tests in parallel.

Thanks for the explanation, that is handy indeed.

Best,

Ismael