Jenkins job for per-repository CI

Jenkins job for per-repository CI

[Andrew Geissler]

Matt Barth is working a story to use his new auto tools capabilities
in each of our repo's to do "make check" calls when code is committed.

For initial prototype work, we created a jenkins job to trigger on
phosphor-event gerrit changes.  That job is here -
https://openpower.xyz/job/phosphor-event-gerrit-trigger/

More to come in the next couple of week.  End goal is a single jenkins
job, using the template plugin, that will trigger on all our repo's
and do the "make check".  Over time we'll add gtests to each of our
repo's to give us more coverage at the individual repo level.

Andrew and Matt

Re: Jenkins job for per-repository CI

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Fri, Nov 18, 2016 at 03:39:24PM -0600, Andrew Geissler wrote:
> For initial prototype work, we created a jenkins job to trigger on
> phosphor-event gerrit changes.  That job is here -
> https://openpower.xyz/job/phosphor-event-gerrit-trigger/

Are you going to convert that over to a template job so that we do not
need to create (and manage) a new Jenkins job for each repository?

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Jenkins job for per-repository CI

[msbarth]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

Yes, that is the plan. This was just a step in getting the initial 
scripts working correctly with Jenkins as the openpower.xyz Jenkins 
server is different than the test Jenkins Andrew setup for me to 
prototype in.


On 11/18/2016 04:54 PM, Patrick Williams wrote:
> On Fri, Nov 18, 2016 at 03:39:24PM -0600, Andrew Geissler wrote:
>> For initial prototype work, we created a jenkins job to trigger on
>> phosphor-event gerrit changes.  That job is here -
>> https://openpower.xyz/job/phosphor-event-gerrit-trigger/
> Are you going to convert that over to a template job so that we do not
> need to create (and manage) a new Jenkins job for each repository?
>
>
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc


[-- Attachment #2: Type: text/html, Size: 1651 bytes --]

Re: Jenkins job for per-repository CI

[Joel Stanley]

Hi Matt,

You need to set your username in Thunderbird. I also recommend not top
posting and disabling HTML mail when sending to mailing lists.

On Sat, Nov 19, 2016 at 8:09 AM, Andrew Geissler <geissonator@gmail.com> wrote:
> Matt Barth is working a story to use his new auto tools capabilities
> in each of our repo's to do "make check" calls when code is committed.

Cool! I assume make check will be used by developers on the local
machines too. I think it's important that our development process is
as frictionaless as possible. To that end, someone should be able to
git clone && autoreconf && ./configure && make check wherever
possible.

This is harder for projects that have cross-project dependencies. How
are you handling these cases?

Do you have any code for us to look at?

Cheers,

Joel

Re: Jenkins job for per-repository CI

[Matt Barth]

Hey Joel,

On 11/20/2016 06:47 PM, Joel Stanley wrote:
> Hi Matt,
>
> You need to set your username in Thunderbird. I also recommend not top
> posting and disabling HTML mail when sending to mailing lists.
>
Thanks for the pointers, think I fixed things on this now.
> On Sat, Nov 19, 2016 at 8:09 AM, Andrew Geissler <geissonator@gmail.com> wrote:
>> Matt Barth is working a story to use his new auto tools capabilities
>> in each of our repo's to do "make check" calls when code is committed.
>
> Cool! I assume make check will be used by developers on the local
> machines too. I think it's important that our development process is
> as frictionaless as possible. To that end, someone should be able to
> git clone && autoreconf && ./configure && make check wherever
> possible.
>
Correct, this should be able to be done by developers on local machines 
within a x86_64(most likely) SDK or without a SDK if all the 
dependencies are met.
> This is harder for projects that have cross-project dependencies. How
> are you handling these cases?
>
At this time, the dependencies will be up to the developer when 
attempting to run locally(SDK or not). There's likely some work still to 
be done here where ./configure should report any missing dependencies 
for the developer to correct.
On the Jenkins automation side, I'm working on a script to parse 
configure.ac in determining what dependencies need to be installed 
within the docker image prior to running the unit tests. This is a work 
in progress at the moment and will possibly cause updates to each repo's 
configure.ac file to better define the dependencies.
> Do you have any code for us to look at?
>
There's a couple commits in gerrit for the Jenkin's scripts to build and 
run the docker image and I'm working on the script that runs within the 
docker image to determine these dependencies now.
https://gerrit.openbmc-project.xyz/#/c/1103/
https://gerrit.openbmc-project.xyz/#/c/1230/
> Cheers,
>
> Joel
>
Matt