On Fri, Sep 27, 2013 at 10:05:01AM +0200, Michael Tautschnig wrote:
> Hi Zack, hi all,
Hi!
> Would you/Matthias be willing to share the feedback on jenkins more widely? I do
> presently run a system with ~60,000 jobs, and, yes, this is probably somewhat
> beyond what jenkins was meant to scale to. Yet jenkins does have the practical
> advantage of being widely used, with lots of plug-ins, and being well
> documented. Not all of this seems to be the case for debile at present...
The case for debile isn't the case for Jenkins. They're different tools
that *can* do similar things, but in very different ways.
Debile is intended to work in "The Debian Way" - in so far as it
understands what a source package is, what a binary package is, and can
properly grok related stuff like suites, etc.
Debile will have a plug-in archetecture, but this is not really the
point. The point is that it will manage a given source package, and hand
this out to build nodes for each arch (amd64, i386, armhf, armel, all), which
will build for it's suite (stable, unstable, testing, any/all), and push
the results back up.
In addition, it can run static checks, and push the results back in a
standard format (Firehose), which I've been working on closely with a
red hat engineer, so that we can have compatable static result data.
By 1.0 this will be smart enough to allow for:
* proper rebuilds of a source package (I need to upgrade Django. Let me push
it here and rebuild anything depending on Django to see how it works)
* use for mentoring (run *tons* of static checks on it)
* a gateway for normal DD uploads (push a package there, run all sorts of
tests, if it passes piuparts, adequate, etc, then dput to
ftp-master, otherwise destroy the upload and email),
* and ongoing QA tool (rebuild all uploaded arch:all packages)
To be honest, only the last part is something jenkins is suited for, and
the actual "CI" part consists of a bot that watches for d-d-c emails,
and uploads the package from incoming.d.o -> debile's internal incoming.
Long term goals include proper dependency resolution and management,
using something basic to start (topological sort?), and growing more
complex until we're using apt's resolver (I assume, none of this is
planned, just ideas), to do lightweight $WORLD rebuilds (of course, this
will not be fit for bootstrapping, unless a bootstrapper gets involved)
> > I don't doubt that jenkins.d.n can be leveraged for the time being,
> > giving the low amount of autopkgtests currently available. But you might
> > want to check with Matthias or similar experiences before committing to
> > using Jenkins for this.
> >
> I'd be happy to contribute mine as well, and one of the key points seems to be
> the level of interaction/user control people are looking for.
Jenkins rocks, it's just not what Debile's for. They're not competing.
I would never use debile to build nightly debs, for instance. I'd just
jenkins. At best, I'd use jenkins and dput to a debile build setup.
>
> Best,
> Michael
Thanks for your interest, mt!
Paul
--
.''`. Paul Tagliamonte <paultag@debian.org>
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`- http://people.debian.org/~paultag
Attachment:
signature.asc
Description: Digital signature