continuous integration

[jelle feringa]

What are the thoughts of the OCE devs on the subject of continuous integration?

I the threads I often see that certain commits break things when compiled on another platform.

I'm curious to hear what your thoughts are on continuous integration and if its something we should look into?

-jelle

[D. Barbier]

Hello Jelle,

I agree, continuous integration is very helpful. We need:
1. A server to gather reports from clients
2. Clients performing automated builds

The main problem is (1); Thomas tried CDash, see this thread:
https://groups.google.com/d/msg/oce-dev/uMuZJPrliD4/BImfysjuPjYJ
He could not use the free CDash server provided by my.cdash.org to run
code coverage tests, but maybe we can use it for automated builds.

Denis

[jelle feringa]

CDash makes sense, given OCE's commitment to CMake, CPack and CTest.

Thans for pointing out that interesting thread.

Jenkins might be an interesting option too.

I'm not sure if I understood it right, but basically, you'd have an instance of Jenkins performing CI on your local machine, while being activated through github commits.

This would trigger the build and share the results on github.

I'd be happy to have my workstation run as a CI instance, since its on 24/7 anyway.

If we have 2 other instances for linux, that would offer basic coverage, and we can explore more exotic configurations from there.

Would you say its worth a shot Denis, or should we go with CDash?

I guess a similar setup can be sorted out.

I'm curious whether you value the Jenkins integration in github.

-jelle

[D. Barbier]

On 2013/4/30 jelle feringa wrote:

> CDash makes sense, given OCE's commitment to CMake, CPack and CTest.
> Thans for pointing out that interesting thread.
>
> Jenkins might be an interesting option too.
> I'm not sure if I understood it right, but basically, you'd have an instance
> of Jenkins performing CI on your local machine, while being activated
> through github commits.
> This would trigger the build

Yes.
A simpler setup is to let Jenkins poll the source repository every $x
minutes and perform build/tests if there are changes, this does not
require any change to the current github setup.

> and share the results on github.

AFAICT, no.

> I'd be happy to have my workstation run as a CI instance, since its on 24/7
> anyway.
> If we have 2 other instances for linux, that would offer basic coverage, and
> we can explore more exotic configurations from there.
>
> Would you say its worth a shot Denis, or should we go with CDash?
> I guess a similar setup can be sorted out.
> I'm curious whether you value the Jenkins integration in github.

I do not know Jenkins, I have some experience with CruiseControl.
Both are CI software, whereas CDash is different, it gathers reports
from CI clients.

Denis

[D. Barbier]

One more point about CI; it should be pretty straightforward to run
one or several nightly builds and send automatic reports to
http://my.cdash.org/index.php?project=OCE
But I do not see how to build automagically the pull requests before
they got merged into master, which is our real need.
Does someone knows a solution?

Denis

[Thomas Paviot]

2013/4/30 D. Barbier <bou...@gmail.com>

Denis,

I don't understand what you mean with "build automagically the pull requests". You mean "merge all the branches that are part of a pull request process" before building master, right? Note that the build does not necessary has to be the master branch, we could have a branch named 'ci', on top of master, in which all review/* branches are merged before the branch is compiled.

Thomas

 

[jelle feringa]

If I'm still following along, perhaps that at the individual developer an instance of Jenkins runs, which will trigger the built and <possible?> reports to the CDash server?

[D. Barbier]

2013/4/30 Thomas Paviot <tpa...@gmail.com>:

> 2013/4/30 D. Barbier <bou...@gmail.com>
>>
>> One more point about CI; it should be pretty straightforward to run
>> one or several nightly builds and send automatic reports to
>> http://my.cdash.org/index.php?project=OCE
>> But I do not see how to build automagically the pull requests before
>> they got merged into master, which is our real need.
>

> I don't understand what you mean with "build automagically the pull
> requests". You mean "merge all the branches that are part of a pull request
> process" before building master, right?

No, I was thinking of testing each branch separately, so that a
failure in a branch does not prevent other branches from being merged.
The workflow I have in mind is:
* someone makes a pull request
* CI clients perform nightly builds of each pull request (merged
locally into master)
* we comment pull requests as today, but do not have to wait for
porters since CI takes care of detecting porting problems
* before merging a branch, we ensure that all dashboards for this
branch are green

> Note that the build does not
> necessary has to be the master branch, we could have a branch named 'ci', on
> top of master, in which all review/* branches are merged before the branch
> is compiled.

Can you please describe the workflow you have in mind? Who will
manage the ci branch? What happens when a pull request is dismissed?

Denis

[QbProg]

I Still didn't tryed it , but what about :
https://buildhive.cloudbees.com/