Produce artifacts from CI with Mapnik XML

[pnorman]

cc @lonvia

With the increasing problems of getting npm and carto, some have asked about having artifacts generated from CI with the Mapnik XML

[kocio-pl]

Could you be more verbose, please? I don't get what's this ticket about and what kind of problems are you mentioning.

[pnorman]

Could you be more verbose, please? I don't get what's this ticket about and what kind of problems are you mentioning.

Requiring a npm install is a reasonably high barrier if you only want to use the style, not develop it. If all someone needs is the XML, they should be able to get that as an artifact.

[lonvia]

I was the one asking about artifacts, so let me elaborate. npm does not ship as a package with Debian anymore. The manual installation instructions for npm ask you to pipe a script from the internets into a sudo bash, which is a no-no for obvious reasons. In the end I settled for nvm to set up a current nodejs and npm without requiring root. It's still quite a bit of work, so precompiled XML for those of us who just want to render would be awesome.

I've looked a bit into what Travis can do. Unfortunately, it does not host artifacts itself like appveyor does. So you need to provide some hosting. The most promising might be the uploading to Github releases. Having xml for the releases would be more than enough for non-devs.

[kocio-pl]

Any ideas about how it should be done? Probably some simple script to be launched before every release or just a one liner in RELEASES.md?

[HolgerJeromin]

Another way would be letting travis checkin the results to an repository. Not kidding

https://github.com/open62541/open62541/blob/master/tools/travis/travis_push_release.sh
produces https://open62541.org/releases/

[kocio-pl]

Sounds great to me. Anybody willing to prepare the code?

[HolgerJeromin]

Its kind of hacking github for serving files without the need of the full history.
The downside are the massive checkins which floods the history of the repository. Thats why it seems a good idea to use another repository and reset it from time to time:
open62541/open62541#108

[pnorman]

👎 on having travis push to a git repo.

We could either have Travis push to github releases, another artifact location, or look at something like circleci which has artifact support.

[matkoniecz]

I am against giving push access to external entities.

Separate repo would be acceptable for me or something similar.