Continuous Integration and Cross Compilation

Herbert Valerio Riedel hvriedel at gmail.com
Mon Jul 7 07:19:28 UTC 2014


On 2014-07-07 at 03:40:17 +0200, William Knop wrote:

[...]

> I think using Jenkins may be a step in the right direction for a few reasons:
>
> • there are hundreds of supported plugins [1] which cover notifications, code review [2], cloud computing services, and so on
> • there is quite a lot of polish as far as generated reports go [3]
> • it seems easy/nice to use out of the box (from a few minutes’ fiddling on my part)
>
> Now, I don’t have much experience with buildbots, so I may be unfairly
> elevating Jenkins here. If buildbots can be easily extended to do
> exactly what we need, I’m all for it, and in that case I’d volunteer
> to help in that regard.

Btw, one feature I don't know how to achieve with Jenkins (yet):

 - Try to build/test every single commit, while
 - priorizing latest commits,
 - work its way back during idle-time

(which is more or less what http://bitten.edgewall.org/ does)

For GHC, since it's properly submoduled now, it would suffice to test
each single commit in ghc.git. Having easily accessible metrics for each
single commit (on various configurations) would be very useful. 

For instance, knowing the last-known-working commit is especially
important if the latest commit fails to build (or exhibits some other
significant metric regression). In some cases this can save developers
time to git-bisect manually, as the answer is already in plain sight.

Does anyone have any idea how so set something like that up with
Jenkins?

Cheers,
  hvr


More information about the ghc-devs mailing list