Travis CI

[pnorman]

Travis needs to be enabled on this repo for this to work, but this will check that the .mml file is valid JSON and that carto compiles it without errors. See pnorman#2 for an example of how it looks.

[gravitystorm]

Interesting stuff! Should at least handle the most egregious pull request problems. I've enabled it with travis-ci.org so we should start seeing results today.

I've just read in the documentation that updates to the upstream don't trigger rebuilds, i.e. stale pull requests might remain marked as passing even after master gets more patches. Roll on #711 !

[matthijsmelissen]

Nice. I wonder what more we can do with this.

We sometimes often pull requests that only serve to refactor the code without intending to change the resulting map. Would there be any way to test this automatically, given an example osm file for example? It would also be nice if we could show that a PR that changes POIs does not have influence on road rendering, and vice versa. Both involve comparing the output with the previous version, so I'm not sure if Travis CI is the right way to handle this.

In general, are two generated PNG files from the same (or equivalent) carto/mapnik code expected to be bit-by-bit equal, or is there a level of nondeterminism?

[pnorman]

In general, are two generated PNG files from the same (or equivalent) carto/mapnik code expected to be bit-by-bit equal, or is there a level of nondeterminism?

The PostgreSQL layer has parts that are both undefined (ordering of tables) and nondeterministic (GiST index pick-split) code.

travis is not the right way to handle this, as a PR that changes rendering is not in error for that fact alone.

I'd be happy simply checking that all SQL works - that there are no columns referenced in the style that aren't in the query, etc.

[matthijsmelissen]

that there are no columns referenced in the style that aren't in the query,

That would certainly be helpful.