From owner-freebsd-ports@FreeBSD.ORG Mon Aug 6 10:41:00 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A96611065679; Mon, 6 Aug 2012 10:41:00 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CAA638FC16; Mon, 6 Aug 2012 10:40:59 +0000 (UTC) Received: by eeke52 with SMTP id e52so737620eek.13 for ; Mon, 06 Aug 2012 03:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t7bvsDvoa0jwl8zbs96gQqQeEfb7LTmUj+7NgYPjMWg=; b=MdJqIzLEL+4HqOh3pF3IwXVm+XwqC5cMJRhdyf/1SADGbC3KFyLjTQNw+ymzPVVBjK eLczghOaf28JMbHbsxqQzZI1Uj/pUpHHNWt7Gshu/sdV+MAo0g73zOt4AbsH6cgC7N9y 79JhUb5vxMp17VwoRUYv48otamPNAImNmMym8TQddcFE/iK8gKAnyz8xXHaxX6ngbv67 frMUkHCb+gI+NhMrjCtcgQHje8hlR4Lb+vqweebgYvAWqohzVoLre1jrAKZG3nC5E16l DH2bR/EPjl5lc/y4+Ds1QvmvIeqHQr67scKy/zCU6Q4/nYdfVi4muapgDTk4y/0tleKR WfMA== MIME-Version: 1.0 Received: by 10.14.172.193 with SMTP id t41mr12366498eel.25.1344249653041; Mon, 06 Aug 2012 03:40:53 -0700 (PDT) Received: by 10.14.216.70 with HTTP; Mon, 6 Aug 2012 03:40:52 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Aug 2012 13:40:52 +0300 Message-ID: From: Marin Atanasov Nikolov To: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ml-freebsd-stable , freebsd-ports@freebsd.org Subject: Re: Jenkins+FreeBSD handbooks X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 10:41:00 -0000 On Sun, Aug 5, 2012 at 8:37 PM, Bernhard Fr=F6hlich wro= te: Hello Bernhard, Thank you for the feedback. >> Could you clarify a bit more why you think Jenkins does not fit well the= re? >> >> I don't know how redports.org 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 li= ke > 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 a= nd > 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 break= s is > non trivial. Not to talk about all the special customizations that we nee= d > 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 j= ust > 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 bu= t > 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. Pr= obably > there is a plugin for that but I didn't find it. Writing some glue code a= round > 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 deployed. 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 automatically. - 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, Marin > > -- > Bernhard Froehlich > http://www.bluelife.at/ --=20 Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/