On 16/12/2008, at 11:51 AM, Jason van Zyl wrote:
By layering I think that a canonical system should be picked, say Ubuntu, and that should be a fast compile-only smoke test to look for breakages. If that works trigger the tests, if that works propagate to the grid, do the build and run the ITs. Then layer in plugin tests maybe daily. That may not be the perfect workflow and we should put this in the wiki.
+1, something like this sounds good.
Tom/John, I don't know how long it will take to finish the maven integration testing plugin and get all the nodes updated. But I can do the dirty trick that I did before which was the let the bootstrap feed into a predefined Maven installation location. I just want to get the ITs triggered correctly using the version of Maven built by the bootstrap.
I still don't quite get the approaches being used here. Can someone clear up all the pieces for me?
- we have deployment of the IT plugins to a repository even as snapshots, though I thought it was required to be pre-installed based on the bits below? - maven-integration-tests checks out the ITs from trunk but how does that integrate with Hudson's existing SCM checks? - Hudson plugins are meant to coordinate running with a version instead of requiring the above?
I agree there needs to be one standard way to do these things, but I'd like to understand the technical reasons for choosing the bootstrap, etc. over the unpack-and-run approach of maven-core-it-runner before it disappears completely. The only one I've heard described was the possibility of the IT artifacts in the repo being out of date, but that's irrelevant in a CI situation and they seem to be getting deployed above anyway.
To me, the approach is much more Maven-y by reusing the repository and ordering, and it's easy to understand. Where did it not address the needs in setting this up?
I also think it makes sense to release the integration tests that were used to verify a particular release of Maven so we always have that locked in. Otherwise as the ITs change, we have a different measure of what worked in 2.0.x and what didn't. The runner approach is much better suited to this rather than checking it out from a tag each time.
Benjamin, you've basically done all the work for the ITs so far. You think you might sketch out in the wiki what you think would be ideal? At this point I think we defer to you as you've been working on them so long.
Benjamin++ :) Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
