It's easy to enable (I've added the two required lines but they're commented out just now).
The only problem is that there's immediately a bunch of tests that fall into the category of added-but-failing. :( Not hard - just a logistical exercise. On 27 Jul 2011 20:33, "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: >>
