Is it feasible to consider decoupling the database-specific tests from the commit-triggered-build altogether and running the database-specific tests as part of either a regularly-scheduled once-per-day build or as an on-demand build? If they increase the length of the CI feedback loop unacceptably, this might permit us to both benefit from having them wired up but also sidestep the negatives associated with them.
Thoughts on the viability of this approach --? Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Wed, Jul 27, 2011 at 3:33 PM, Patrick Earl <[email protected]> wrote: > From my perspective, we should take on other databases if: > > a) The team agrees that the general popularity of the platform > warrants it. (ex. Oracle) > b) A team member "adopts" the database (ex. SQLite and PostgreSQL were > adopted by me). > > Regarding the build times, I believe that this is something inevitable > that we should embrace. The more tests that occur automatically, the > more quickly we understand and correct problems with different > databases. Tests for one database might even illuminate bugs that > aren't apparent with other databases. Since it's very expensive to > have every developer set up every database and run all the tests on > all the databases, I believe the build server is the right place to do > this. There just needs to be the expectation that committers will > handle fallout from their commits within a reasonably short time > period, something that I don't believe will be a significant issue > going forward. > > Since it sounds like the popular opinion, we should go ahead and make > the tests fail if new tests fail. I'll be presumptuous and hope that > Richard will change it since he's most familiar with the territory. :) > > Patrick Earl > > On Wed, Jul 27, 2011 at 9:45 AM, Julian Maughan > <[email protected]> wrote: > > I totally agree. The only problem I have is just how long it takes to run > > the tests on all instances. Not having an Oracle database may be costing > us > > some credibility, but otherwise I would suggest not adding more. > > > > The other issue is how the CI databases are chosen. We are essentially > > giving these database vendors/projects a 'first class' status compared to > > others. > > > > On 22/07/2011 6:47 AM, "Patrick Earl" <[email protected]> wrote: > > >
