mapnik3

[yhahn]

This will require a major semver version bump -- (2.0.0)

[yhahn]

@springmeyer interesting failures on windows for TIF/KML: https://ci.appveyor.com/project/Mapbox/mapnik-omnivore/build/1.0.139/job/3vya14qow57343bi

[springmeyer]

Interesting. Those Mapnik LOG entries are warnings rather than errors and should be happening I think. So, I'm confused then why mocha is actually erroring...

[coveralls]

Coverage remained the same when pulling fcb97d2 on mapnik3 into 6f5cde0 on master.

[springmeyer]

So, I'm realizing that mapnik-omnivore has never worked on appveyor. All previous runs were against node v0.11.x which failed to ever run the tests because node-gdal fails to build against node v0.11.x. Due to the allow_failures all builds looked like they were passing.

Now that we are testing against node v0.10.x the tests are actually running.

I see that the mapnik3 branch tests work just fine on my Windows VM so the problem is not mapnik-omnivore but rather that appveyor+node v0.10+mocha is borking on the STDERR from Mapnik's logging. The logging I feel is important because layers without features are odd. So we can just ignore these test failures, port to tap, or move on mapnik/node-mapnik#300 to be able to silent the logging.

[GretaCB]

Yeah, the warning logs are expected for GPX sources. It's happening somewhere in here: https://github.com/mapbox/mapnik-omnivore/blob/master/lib/datasourceProcessor.js#L613-L623
A little while back, Dane and I chatted about this, and I just decided to leave the warning logs.

Perfect (d6fb44b), thanks @yhahn . I just did the same in unpacker tests for center. Was wondering if this would pop up in other local env's in mapnik-omnivore.

@springmeyer , we ended up having to change the mocha script (9baff42) a while back due to something like this. I'm assuming this is related?

[springmeyer]

@springmeyer , we ended up having to change the mocha script (9baff42) a while back due to something like this. I'm assuming this is related?

Hmm, can you say more? I don't know.

[GretaCB]

@springmeyer The ticket I was thinking of (https://github.com/mapbox/DEAD-unpacker-shapefile/issues/14). This was in unpacker before mapnik-omnivore was split out.

[yhahn]

: | having trouble tracking the appveyor issue down -- can't reproduce these fails on my VM. I think next action for me is to switch the tests over to tape from mocha which has been much better for us on appveyor.

[GretaCB]

@yhahn I can work on switching over to tape

[yhahn]

Tradin

[coveralls]

Coverage remained the same when pulling 2e478c8 on mapnik3 into 6f5cde0 on master.

[coveralls]

Changes Unknown when pulling f1eb504 on mapnik3 into * on master*.

[coveralls]

Changes Unknown when pulling dd33b39 on mapnik3 into * on master*.

[yhahn]

👍 tape 2/3 times on appveyor and time #2 actually was a pass but appveyor didnt know it