CI integration (nightly and PR validation)

[dragos]

The IDE build depends on Scala modules, and without nightlies or PR validation we can regress in a module release.

[gkossakowski]

I think we can agree that if dbuild doesn't deliver that for us soon (2-3 weeks) we'll need to setup jenkins jobs manually. I think the risk of regression is much lower compared to something as big and as frequently changed as compiler.

[adriaanm]

I'm working on this now using Travis CI -- see #11. Liking it so far!

[adriaanm]

Wow, took less than two minutes to set up! Next step: a nightly dbuild of all modules.

[adriaanm]

We still need nightlies to test integration, but every commit is being built and tested against 2.10.3 and 2.11.0-SNAPSHOT

[SethTisue]

this is now adequately covered by Travis, isn't it?

[biswanaths]

https://travis-ci.org/scala/scala-xml/builds is travis build history for every commit.

I can't find any nightlies builds or test integration builds.

[SethTisue]

another piece of the CI picture is that the community build builds and tests the latest scala-xml commits (and not just in isolation, but in the context of every project in the build that uses XML).

(because of scala/community-build#154, scala-xml gets built with a released compiler, not with a bleeding-edge compiler, but oh well)

[ashawley]

@SethTisue Can this be closed? Are community-builds able to give fair warning when commits here at scala-xml are going to negatively affect downstream users?

[SethTisue]

Are community-builds able to give fair warning when commits here at scala-xml are going to negatively affect downstream users

with the possible exception of ScalaIDE, I think so, yes. closing.

re: ScalaIDE, pinging @sschaef @wpopielarski — you can take it up or not as you see fit

[SethTisue]

scala-xml gets built with a released compiler, not with a bleeding-edge compiler

note that this was fixed a while back (for 2.12+ anyway)