Setup continuous integration

[aperezdc]

This may be a bit hard, as we would need a full WebKit WPE build available in the build environment, and the “easy” options directly supported in GitHub like Travis-CI of course do not have it.

From the top of my head, the following sound like could work:

• Providing prebuilt tarballs with the dependencies which the CI just unpacks, and points things around (LD_LIBRARY_PATH, and so on) so the prebuilts can be found.

• Using some CI system which allows specifying a base image which is used for building/testing, and the base image already includes the needed dependencies preinstalled.

In both those cases we need to, now and then, make either tarballs or images with the needed dependencies, so for simplicity I am leaning towards the tarball with binaries.

[clopez]

You can use the webkitgtk that is available via apt-get and build dinghy with gtk support. Better than nothing.

Aso, with gtk is easier to run it inside Xvfb with mesa swrast, so you can even run actual tests (open a page, run a benchmkar) and check that the console.log or something like that gives the expected output.

[aperezdc]

@clopez: While that's a good idea, unfortunately readily available base images tend to be old. For example Travis-CI is stuck in Ubuntu Trusty, which has WebKitGTK+ 2.4.x 😞

[clopez]

@clopez: While that's a good idea, unfortunately readily available base images tend to be old. For example Travis-CI is stuck in Ubuntu Trusty, which has WebKitGTK+ 2.4.x

There are ways around that:

• Pull a docker image and do the tests inside docker (that way you can also have wpe tests as you can build and publish your own docker image with wpe if you wish)
• Use an external ppa that provides updated webkitgtk or updated wpe (as you can also publish and use your own ppa packages) but i think the docker option will be less painful