Fix for bug #1629

Paul Ramsey pramsey at REFRACTIONS.NET
Fri Feb 3 11:09:47 EST 2006


One of our April projects at Refractions is going to be a continuous  
build/test server for udig/geotools that will run cruisecontrol and  
full build/test sets all the time, against (and here is the tricky  
bit) all the data stores.  So the server will also have instances of  
PostGIS, Oracle, SDE, DB2, MySQL and so on set up.  With that basic  
infrastructure we should be able to run the Mapserver tests against a  
broad swath of data stores too, which should hopefully find some of  
the breakages which various folks find "obscure" because they don't  
have the particular server available when they test.

On 3-Feb-06, at 3:50 AM, Umberto Nicoletti wrote:

> I think we need to setup a server that will check out the sources
> every night from cvs and will build them along with performing the
> tests. The report would then be mailed to the mapserver-dev.
>
> This central server then would have a standard environment that could
> be replicated by the interested parties on their workstations if they
> wanted to setup automated tests privately.
>
> There could also be many different builds with different versions of
> gdal, proj, with or without wms, etc. Should we make this an rfc,
> maybe?
>
> Regards,
> Umberto
>
> On 2/2/06, Sean Gillies <sgillies at frii.com> wrote:
>> On Feb 2, 2006, at 8:40 AM, Frank Warmerdam wrote:
>>
>>> On 2/2/06, Sean Gillies <sgillies at frii.com> wrote:
>>>> At the end of 2005, I committed a PostGIS DB makefile to mapserver/
>>>> tests/makefile_postgis. The Python unit tests use this fixture.
>>>
>>> Sean,
>>>
>>> I just tried it and I see it depends on user postgres existing.  I'm
>>> not saying this is a bad assumption, but I will suggest it is  
>>> exactly
>>> these sort of environment differences that make RDBMS based
>>> autotesting difficult.
>>>
>>
>> Agreed. At least it's a start.
>>
>> Sean
>>



More information about the mapserver-dev mailing list