Jenkins+FreeBSD handbooks

Marin Atanasov Nikolov dnaeon at
Mon Aug 6 10:41:00 UTC 2012

On Sun, Aug 5, 2012 at 8:37 PM, Bernhard Fröhlich <decke at> wrote:

Hello Bernhard,

Thank you for the feedback.

>> Could you clarify a bit more why you think Jenkins does not fit well there?
>> I don't know how is designed and how it scales, but with
>> Jenkins it's quite easy to create a package build farm for distributed
>> building.
> Redports is a public compile testing environment for FreeBSD ports. So like
> Ports Tinderbox but with a nice multiuser GUI, cluster functionality for
> scaling and an own Subversion tree for the users to commit their ports to.
> Before I decided to write the code myself I had a closer look at Bitten and
> Jenkins. Both could be made into what redports is now but they all have
> their weak spots. Jenkins GUI looks very cluttered and is quite hard to
> understand if you just want to manually schedule a few new jobs for your
> ports as Joe Average. It's also quite hard to understand and complex as a
> developer and administrator so I was concerned that fixing it if it breaks is
> non trivial. Not to talk about all the special customizations that we need
> which would require me to write extensions in Java and understand how
> all that jenkins internals work.

Like any other system Jenkins has it's own learning curve as well, but
once you get to know it,
you see how intuitive it is to use the system.

I agree with you on the Java stuff. That's the one thing I don't like
about Jenkins being Java..

But I can tell from my experience with it so far, that I haven't had
any issues with it, e.g. breaking and spending lots of time figuring
out how to fix it. Maybe one day I will, but so far I'm quite happy
with it :)

> Bitten looked simpler and less complex but would also work for standard
> things but it got me on the right track to use Trac as webinterface and just
> extend Trac with a custom plugin that includes a few simple pages to
> have an overview of jobs and add new ones.
>> Jenkins comes with lots of ready-to-use plugins as well, which makes
>> it easier to integrate a particular thing easier as well and not
>> re-invent the wheel.
> Yeah that is nice and there is almost everything that you can think of but
> none of them did what I needed. A simple web interface for average people
> that don't want to learn Jenkins internals and is easily customizable. Probably
> there is a plugin for that but I didn't find it. Writing some glue code around
> tinderbox to schedule new jobs, checkout repositories and such stuff is
> custom code anyway.
>>> A more suitable place for jenkins would be automatic building our doc
>>> tree on every commit. But I don't know if that doesn't already exist.
>> Yep, that's one of the things we could use Jenkins for, but I would
>> say we could use it for lots of other stuff as well :)
> I'm sure we could. Examples?

Besides the ones I've already posted in my first email (documentation,
scan-build, project test & build, package test & build) on top of my
head I can think of the following examples as well:

- Integration between Jenkins & Gerrit for code review and
collaboration projects.

One possible place where this can be used for example is replacing the
PR system and gnats.

This would allow contributors to send patches directly to the Gerrit
server and behind the scenes Jenkins does all the automatic
verification of a change, e.g. whether this patch applies or not. A
committer then approves and pushes a single button to get a change

This saves a lot of time for committers and contributors as well as
all the test-verify-deploy cycle of a change is done by Jenkins

- Jenkins also supports the concept of upstream and downstream
projects, which makes possible to trigger a build/test/whatever on
other projects when something happens, e.g. changes to a particular
part of the kernel might trigger a specific set of tests to be
performed; port being updated which triggers building of the port and
then deploying to all systems via Jenkins.

Similar thing I use for the pkgng project - a commit triggers a build
on the downstream projects for a) building with gcc; b) building with
clang; c) building documentation; etc..

- You can use Jenkins for doing QA of configuration changes managed by
Cfengine for example.

Just put the Cfengine repository under Jenkins control and let Jenkins
go over a set of verification steps and tests before a change actually
gets merged in. This makes it suitable to ensure you are not going to
break the configuration by making a typo for example.

- I like graphs :)

Having graphs gives a better visibility for example how often a build
fails, who breaks the build, etc. over time.

Jenkins has lots of plugins which generate graphs - you just need to
configure what you need.

And you can use for other cool stuff, but that really depends on the
needs and requirements. So far I've been quite happy with Jenkins and
doing what I needed, and that was the reason for writing these short
handbooks on Jenkins - just to share what I've already learned from it

Best regards,

> --
> Bernhard Froehlich

Marin Atanasov Nikolov

dnaeon AT gmail DOT com
daemon AT unix-heaven DOT org

More information about the freebsd-stable mailing list