Controlling execution order in multiproject build

[Peter Voss]

Hi,

I have 2 projects "main" and "integration-tests". When I run "gradle  
test" the integration tests are always run before the unit tests in  
main are executed. This is not the behavior I like. I want to run the  
unit tests first and if they fail there is no point running the  
integration tests (which take much longer).

I couldn't find any good way to change that order (other than renaming  
the projects). Adding a dependency from :integration-tests:test  
to :main:test is also not what I want. When executing  
"gradle :integration-tests:test" I want to run only the integration  
tests (and all required artifacts to execute them). Also running the  
tests from main would not be required to run the integration tests.

Is there a way to set the execution order of tasks from different sub  
projects without using dependencies?

Thanks for any help,
--Peter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Peter Voss wrote:

> Hi,
>
> I have 2 projects "main" and "integration-tests". When I run "gradle
> test" the integration tests are always run before the unit tests in
> main are executed. This is not the behavior I like. I want to run the
> unit tests first and if they fail there is no point running the
> integration tests (which take much longer).
>
> I couldn't find any good way to change that order (other than renaming
> the projects). Adding a dependency from :integration-tests:test to
> :main:test is also not what I want. When executing "gradle
> :integration-tests:test" I want to run only the integration tests (and
> all required artifacts to execute them). Also running the tests from
> main would not be required to run the integration tests.
>
> Is there a way to set the execution order of tasks from different sub
> projects without using dependencies?
>

Not yet.

You can probably work around this with something like:

task testsInAGoodOrder {
    dependsOn ':main:check', ':integration-tests:test'
}

There's a few options for fixing this problem. One option is for Gradle
to understand that certain types of tasks, such as Test or Checkstyle,
are verification tasks, and to take this into account when scheduling
the tasks. It would schedule verification tasks as early as possible in
the build, and would schedule them in fastest-first order (subject to
dependencies), which would give the earliest possible feedback of a
breakage.


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Peter Voss]

Hi Adam,

On 03.11.2009, at 03:31, Adam Murdoch wrote:

>
>
> Peter Voss wrote:
>> Hi,
>>
>> I have 2 projects "main" and "integration-tests". When I run  
>> "gradle test" the integration tests are always run before the unit  
>> tests in main are executed. This is not the behavior I like. I want  
>> to run the unit tests first and if they fail there is no point  
>> running the integration tests (which take much longer).
>>
>> I couldn't find any good way to change that order (other than  
>> renaming the projects). Adding a dependency from :integration-
>> tests:test to :main:test is also not what I want. When executing  
>> "gradle :integration-tests:test" I want to run only the integration  
>> tests (and all required artifacts to execute them). Also running  
>> the tests from main would not be required to run the integration  
>> tests.
>>
>> Is there a way to set the execution order of tasks from different  
>> sub projects without using dependencies?
>>
>
> Not yet.
>
> You can probably work around this with something like:
>
> task testsInAGoodOrder {
>   dependsOn ':main:check', ':integration-tests:test'
> }

That would only execute tests of integration-tests project. If I use

task testsInAGoodOrder {
   dependsOn ':main:test', ':integration-tests:test'
}

that would still run the tests of integration-tests first.

> There's a few options for fixing this problem. One option is for  
> Gradle to understand that certain types of tasks, such as Test or  
> Checkstyle, are verification tasks, and to take this into account  
> when scheduling the tasks. It would schedule verification tasks as  
> early as possible in the build, and would schedule them in fastest-
> first order (subject to dependencies), which would give the earliest  
> possible feedback of a breakage.

It's more a problem of ordering subprojects. In one of the user's  
guide examples you are using a multi project build with "shared",  
"api" and "services". I would prefer running tests in the following  
order: shared -> api -> services (gradle would run in this order: api -
 > services -> shared). If a test in shared fails I don't want to  
continue with api or services. Or if the api tests fail, it could be  
just due the reason that shared is broken.

I feel that determining the ordering of sub projects should be under  
the control of the build master and not the build system. The user's  
guide says that sub projects are simply ordered in alphanumerical  
order. I would suggest to use the order that is given in the  
settings.gradle file. Would that be possible?

Thanks,
--Peter

>
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Peter Voss wrote:

> Hi Adam,
>
> On 03.11.2009, at 03:31, Adam Murdoch wrote:
>
>>
>>
>> Peter Voss wrote:
>>> Hi,
>>>
>>> I have 2 projects "main" and "integration-tests". When I run "gradle
>>> test" the integration tests are always run before the unit tests in
>>> main are executed. This is not the behavior I like. I want to run
>>> the unit tests first and if they fail there is no point running the
>>> integration tests (which take much longer).
>>>
>>> I couldn't find any good way to change that order (other than
>>> renaming the projects). Adding a dependency from
>>> :integration-tests:test to :main:test is also not what I want. When
>>> executing "gradle :integration-tests:test" I want to run only the
>>> integration tests (and all required artifacts to execute them). Also
>>> running the tests from main would not be required to run the
>>> integration tests.
>>>
>>> Is there a way to set the execution order of tasks from different
>>> sub projects without using dependencies?
>>>
>>
>> Not yet.
>>
>> You can probably work around this with something like:
>>
>> task testsInAGoodOrder {
>>   dependsOn ':main:check', ':integration-tests:test'
>> }
>
> That would only execute tests of integration-tests project. If I use
>
> task testsInAGoodOrder {
>   dependsOn ':main:test', ':integration-tests:test'
> }
>
> that would still run the tests of integration-tests first.

check depends on test, so the above should do what you want.

>
>> There's a few options for fixing this problem. One option is for
>> Gradle to understand that certain types of tasks, such as Test or
>> Checkstyle, are verification tasks, and to take this into account
>> when scheduling the tasks. It would schedule verification tasks as
>> early as possible in the build, and would schedule them in
>> fastest-first order (subject to dependencies), which would give the
>> earliest possible feedback of a breakage.
>
> It's more a problem of ordering subprojects. In one of the user's
> guide examples you are using a multi project build with "shared",
> "api" and "services". I would prefer running tests in the following
> order: shared -> api -> services (gradle would run in this order: api
> -> services -> shared). If a test in shared fails I don't want to
> continue with api or services. Or if the api tests fail, it could be
> just due the reason that shared is broken.

That's exactly what I meant by 'as early as possible' above.

>
> I feel that determining the ordering of sub projects should be under
> the control of the build master and not the build system.

Probably, but we should also have Gradle provide a reasonable experience
without needing anything to be controlled.

Do you have any other examples where you would want to order things
differently to the default?

> The user's guide says that sub projects are simply ordered in
> alphanumerical order. I would suggest to use the order that is given
> in the settings.gradle file. Would that be possible?
>
> Thanks,
> --Peter
>
>
>>
>>
>> --
>> Adam Murdoch
>> Gradle Developer
>> http://www.gradle.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Peter Voss]

On 03.11.2009, at 20:43, Adam Murdoch wrote:

>
>
> Peter Voss wrote:
>> Hi Adam,
>>
>> On 03.11.2009, at 03:31, Adam Murdoch wrote:
>>
>>>
>>>
>>> Peter Voss wrote:
>>>> Hi,
>>>>
>>>> I have 2 projects "main" and "integration-tests". When I run  
>>>> "gradle test" the integration tests are always run before the  
>>>> unit tests in main are executed. This is not the behavior I like.  
>>>> I want to run the unit tests first and if they fail there is no  
>>>> point running the integration tests (which take much longer).
>>>>
>>>> I couldn't find any good way to change that order (other than  
>>>> renaming the projects). Adding a dependency from :integration-
>>>> tests:test to :main:test is also not what I want. When executing  
>>>> "gradle :integration-tests:test" I want to run only the  
>>>> integration tests (and all required artifacts to execute them).  
>>>> Also running the tests from main would not be required to run the  
>>>> integration tests.
>>>>
>>>> Is there a way to set the execution order of tasks from different  
>>>> sub projects without using dependencies?
>>>>
>>>
>>> Not yet.
>>>
>>> You can probably work around this with something like:
>>>
>>> task testsInAGoodOrder {
>>>  dependsOn ':main:check', ':integration-tests:test'
>>> }
>>
>> That would only execute tests of integration-tests project. If I use
>>
>> task testsInAGoodOrder {
>>  dependsOn ':main:test', ':integration-tests:test'
>> }
>>
>> that would still run the tests of integration-tests first.
>
> check depends on test, so the above should do what you want.

It doesn't. Tests of integration-tests still get executed first. The  
fact that ":main:check" is the first dependency in the list doesn't  
mean that it gets executed first. The task testsInAGoodOrder would  
just ensure that both tasks  ':main:test' and ':integration-
tests:test' get executed, but the ordering is still done in an  
alphanumerical manner (as it seems).

>>
>>> There's a few options for fixing this problem. One option is for  
>>> Gradle to understand that certain types of tasks, such as Test or  
>>> Checkstyle, are verification tasks, and to take this into account  
>>> when scheduling the tasks. It would schedule verification tasks as  
>>> early as possible in the build, and would schedule them in fastest-
>>> first order (subject to dependencies), which would give the  
>>> earliest possible feedback of a breakage.
>>
>> It's more a problem of ordering subprojects. In one of the user's  
>> guide examples you are using a multi project build with "shared",  
>> "api" and "services". I would prefer running tests in the following  
>> order: shared -> api -> services (gradle would run in this order:  
>> api -> services -> shared). If a test in shared fails I don't want  
>> to continue with api or services. Or if the api tests fail, it  
>> could be just due the reason that shared is broken.
>
> That's exactly what I meant by 'as early as possible' above.
>
>>
>> I feel that determining the ordering of sub projects should be  
>> under the control of the build master and not the build system.
>
> Probably, but we should also have Gradle provide a reasonable  
> experience without needing anything to be controlled.

Of course. In most cases it is not necessary to control the ordering.  
I would just say that the default behavior that sub projects are  
ordered alphanumerically should be changed. You could use the ordering  
in the settings.gradle file or in the dependsOn. It doesn't make a  
difference for the cases where you don't care about the ordering, but  
it at least gives you the opportunity to control the order easily  
(other than renaming the sub projects).

> Do you have any other examples where you would want to order things  
> differently to the default?

I am not aware of other things right now.

Thanks for your help on this.
--Peter

>
>> The user's guide says that sub projects are simply ordered in  
>> alphanumerical order. I would suggest to use the order that is  
>> given in the settings.gradle file. Would that be possible?
>>
>> Thanks,
>> --Peter
>>
>>
>>>
>>>
>>> --
>>> Adam Murdoch
>>> Gradle Developer
>>> http://www.gradle.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>  http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Narco]

There is issue GRADLE-479 for a long time already.

[Peter Voss]

On 04.11.2009, at 13:53, Narco wrote:

>
> There is issue GRADLE-479 for a long time already.

Ah, cool. Thanks.

--Peter

> --
> View this message in context: http://old.nabble.com/Controlling-execution-order-in-multiproject-build-tp26170477p26195808.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Narco]

Don`t forget to vote for it :)

Peter Voss wrote:

On 04.11.2009, at 13:53, Narco wrote:

>
> There is issue GRADLE-479 for a long time already.

Ah, cool. Thanks.

--Peter

> --
> View this message in context: http://old.nabble.com/Controlling-execution-order-in-multiproject-build-tp26170477p26195808.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email