[SSSD] Experimental CI setup available

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Thu Mar 6 11:29:55 UTC 2014


Hi everyone,

I've thrown together a basic experimental setup of a continuous integration
(CI) system, and I'd like to gather feedback and ideas for further
development.

For now it is Jenkins with two slaves (Fedora 20 and RHEL 7) running on Brno
Lab VMs:

     http://sssd-ci.idm.lab.eng.brq.redhat.com:8080/

It polls "master" and "sssd-1-11" branches every 5 minutes and builds *every*
new commit.

These builds are done by "public_*" projects.

It supports "push-to-CI" workflow, where you can push to either "master" or
"sssd-1-11" branches of sssd-ci.idm.lab.eng.brq.redhat.com:/srv/ci/sssd.git,
authenticating with ssh keys you use to connect to Lab VMs. Like this:

     git remote add ci sssd-ci.idm.lab.eng.brq.redhat.com:/srv/ci/sssd.git
     git push ci HEAD:master

As a result of the above, builds for every commit not in public master (as of
at most 5 minutes ago) will be scheduled. If public branch you're pushing to
has newer commits than your branch, the push will be refused. Feel free to
either use "--force" option, or rebase.

These builds are be done by "private_*" projects.

All builds are done using "reconfig" and "chmake".

Please feel free to try this out.

Now onto not so good news.

Jenkins and its plug-ins seem to be aimed at simply building the latest state
of a branch. As they're tightly integrated to provide the simplest solution
possible, it is hard to make it do anything else. Including building arbitrary
commits, or just building every commit. As a result many things don't quite
work optimally. Including:

A build will not have a link to a Git commit, if it was built in the previous
build. This doesn't seem to be easily fixable.

Notifications about push-to-CI build results will have irrelevant build
statuses, saying things like "build is fixed", or "build is broken". Fixing
this (if it's possible) will involve writing Groovy scripts and applying
hacks.

Builds can only be named with full Git hash, no short hash possible. Fixing
would involve writing Java code and somehow deploying it through the plug-in
system.

Aggregating builds of a single commit, say done on different systems, isn't
possible meaningfully.

It is impossible to reliably produce links to scheduled builds at the moment
of pushing the changes with "push-to-CI". The have to be found in the
project logs manually. And no, search doesn't work for git hashes, and they
can't be used in URLs.

Not related to Jenkins' focusing on latest state building:

Only some result files (test logs ATM) are archived with the builds, as
compression is not quite supported and disk space is limited.

Issues not related to Jenkins:

For now, push-to-CI build result delivery only works for people whose username
matches local part of their e-mail address.

Current setup has very limited capacity: only one build at a time on each of
the two slaves. This is done to simplify testing and maintenance at the
initial phase and is fixed easily.

There are probably some more issues I forgot to mention, but this will do for
now.

As soon as we get some agreeable configuration with Jenkins, I'll try to do a
setup with Buildbot, which doesn't have some of the issues mentioned and we'll
see if we like it better.

Sincerely,
Nick



More information about the sssd-devel mailing list