buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lacton <>
Subject Re: [buildr] Compile and test order
Date Fri, 15 Aug 2008 12:05:54 GMT
On Thu, Aug 14, 2008 at 11:42 PM, Assaf Arkin <> wrote:
> On Thu, Aug 14, 2008 at 2:11 PM, lacton <> wrote:
>> The order of compile and test tasks puzzles me.
>> Let's say we have two projects called foo and bar, and foo depends on
>> bar. Calling the 'build' or 'test' tasks will run tasks in the
>> following order.
>> 1. bar:compile
>> 2. foo:compile
>> 3. bar:test
>> 4. foo:test
>> I would expect 'bar:test' to run before anything is done to 'foo',
>> because whatever is done with 'foo' will probably be a waste of time
>> if 'bar:test' fails. (Unless I know what I'm doing and I choose to add
>> 'test=no' or 'test=all'.)
>> I propose this instead.
>> 1. bar:compile
>> 2'. bar:test  --> build will stop here if a test fails (unless
>> overridden by user)
>> 3'. foo:compile
>> 4. foo:test
>> Is there something I'm missing?  What do you think of my proposal?
> I like it.
> foo:compile depends on bar's packaging task, which in turn depends on
> bar:build which in turn depends on bar:compile, but not bar:test.
> What you're asking is essentially to make bar:build run bar:test.

That's right.  The way I see it, the link between foo and bar is the
package produced by bar and used by foo.  I expect bar to provide a
reliable package to foo (i.e., bar's tests should pass), unless the
user chose 'test=no|all'.

> (The global build task runs the global test task, but for each
> individual project there's no such dependency)
> It will be an easy change, but we need to make sure it doesn't have
> nasty side effects.  Consider this:
> Scenario 1: I'm working on foo, I made some changes to the code, I run
> buildr foo:test.  I did not touch bar in a long while, so there's
> nothing for bar to do, it would be wrong if bar:test runs at this
> point in time.
> Scenario 2: I'm working on foo, I made some changes to the code, but I
> also made some changes to bar.  Now when I run buildr foo:test, I
> expect bar to be compiled, tested and packaged before compiling foo.
> I can't think of anything else we need to worry about, just make sure
> we can do these two scenarios right.

Yes, I agree with these two scenarios.

> Can you think of any other side effects?

Yes, I think I know one. When packages gets updated, their tests will
be run, which is not the case right now.

For instance, let's say we have the following project definition.

define 'example' do
        project.version = '1.0'

        define 'bar' do
                package :jar

        define 'foo' do
                compile.with project('bar')
                package :war
                task 'deploy' => package(:war) do
                        puts 'Deploying the war...'

If I change something in 'bar' and then call 'buildr
example:foo:deploy', the following tasks will happen.
1. bar compilation
2. bar.jar packaging
3. foo compilation
4. foo.war packaging
5. foo.war deployment

If we implement the change we're discussing, then the following tasks
will happen instead.
1. bar compilation
2. *** bar testing ***
3. bar.jar packaging
4. foo compilation
5. *** foo testing ***
6. foo.war packaging
7. foo.war deployment

I think testing bar and foo is a good default behavior in this
context.  I also think this execution order minimizes waste should an
issue arise at some point.


> Assaf
>> --
>> Lacton

View raw message