Frequent reason for build failures.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Frequent reason for build failures.

hans_d
Administrator
In our build sources we have a class called VersionTest. As it is  
located in the build sources it can't access our Helper classes from  
the main test branch. Therefore it has to create a test project and a  
project factory. If we change for example the constructor arguments  
we have to change this test. The problem that the CI build does not  
detect this as long as it runs with an old wrapper version.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Frequent reason for build failures.

Adam Murdoch-2


Hans Dockter wrote:
> In our build sources we have a class called VersionTest. As it is
> located in the build sources it can't access our Helper classes from
> the main test branch. Therefore it has to create a test project and a
> project factory. If we change for example the constructor arguments we
> have to change this test. The problem that the CI build does not
> detect this as long as it runs with an old wrapper version.
>
I have wondered about how to handle this. I break this almost ever time
I make changes, but I use the wrapper to run the tests before I check
in, so I don't notice. I don't really want to update the wrapper every
time these things change, either.

Having a look at the test, I can think of a few options to make these
types of breaks less likely:

1. Use a mock Project, so that the coupling is to the interface rather
than several implementations

2. Treat the project object as a dynamically typed object, rather than
declaring it as project

3. Introduce an interface which represents a versioned thing, which
Version could use and AbstractProject could implement.  If we changed
BaseDependencyManager to use this as well, instead of Project, then
DefaultSettings could implement this interface and we wouldn't need to
create the dummy project for the settings' dependency manager.

4. Move Version into the main source tree, and possibly into the
beginnings of a release management plugin.


I think 4 is the best option.


Adam

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

    http://xircles.codehaus.org/manage_email