 Okay, hello. I start with some disclaimers that I'm overworked from DevCon, if you probably guess. Sorry that I didn't have time to prepare the talk, but I'm also at one inbox zero at the moment. Well, the CCC Hamburg we're just trolled at the moment by some Nazi and this has broken out eight days ago a huge flamable and I wish I could have ignored it, but I failed. The CCC will be fine. I think the CCC Hamburg will not be fine at all. Yeah, I'm not... I'm just saying this. Dainazi is gone. But let's have ponies now. Jenkins has ponies. I'll have a short intro, a live demo and what mostly what I want is to discuss how to use Jenkins in Debian. Yeah, this is some stuff about me. Whatever. Who knows what Jenkins is? Some people Who uses Jenkins? Okay. Who wants to use it? Okay. Jenkins is a continuous integration server. It's basically, I say it's a chron on steroids with nice reporting and stuff. The package description is Jenkins monitors execution of repeated jobs such as building a software project or jobs run by chron. Among these things, current Jenkins focus on the following two jobs. Building testing software projects continuously. So basically, you can configure it to build on every commit for all branches or just for certain branches. And it also monitors jobs, so it does reporting, creates statistic automatically. Yeah, and generally it's very easy to set up and quite immediately produces nice results. Graphs and stuff. It was started in 2004 by Kozuka Kawaguchi. I hope I pronounced this somehow right. Used to be named Hudson and was forked last year. Drives some issues with the new ownership from Sun to Oracle. Jenkins itself is released under the MIT license mostly. There are some other bits, but not much. The community is quite friendly and very active. There are more than 800 plugins. And Jenkins is released every week, every Monday. There's a new release and long-term releases are done roughly four times a year. Jenkins is quite heavily used. Many big names are using it. Michael Kropot made a list of free software projects which is using Jenkins. The upper list with Apache and Django and whatnot. They have all public Jenkins instances. So if you want to peek at Jenkins, I'd suggest you go to these pages and look at Jenkins live. The Debian package has been done by James Page. You can just do up, can install Jenkins in Weezy. That will install the long-term release of Jenkins and from there you can install all the plugins. There are some plugins have been packaged in Debian, but you can also just install them from upstream and you can also upgrade the Jenkins from upstream. You have to show you Jenkins. This is how it looks on my test instance. We've set up one job building PO parts and so it automatically here shows the previous build. It automatically creates trends how long the build time takes. So it takes 26 seconds in average. And you've configured it to build. I need to check the branch, the developer branch. So That's still not quite readable. Pardon? Oh, how do I do this? I don't have GNOME terminal installed. How do I change the colors? How do I do it next time to change the colors? So let's do some stupid change in the build. Oh, it builds from upstream so I I configured it to get the upstream so I need to push something there, which is stupid. So it Now it will start building here. Hopefully. Why doesn't this work? That's the problem with live demos. Anyway, it would build and it will then create the normal build lock Which is here the console output Which has the output of the job Normally it will not send emails if for a successful build, but if the build fails it will send an email Until the first successful build again, so it's also it doesn't it's very quiet What else? I'm really not prepared. For Debian, I was thinking about building automated CDs like every day and running tests on this Or try or build DI on every commit. I don't think it's useful to build production cost code on Jenkins because Normally in a corporate environment There's one of a few people who control the Jenkins instant while I wouldn't want this for Debian And so I cannot really imagine how to have it open Jenkins where everybody can Maintain projects and have it secure. So I think for Debian usage is better to have it just for QA stuff And that is basically my talk Do you have suggestions? What do you do with Jenkins and Debian context? so I've not been using Jenkins, but I do do an awful lot of automated building using rebuild D Which is a bit thick, but it does work and I wonder whether So the thing that's difficult to do is Repeated different ways of building the same package if you want to build a package Same version in the same package several different ways using different tools The problem then is that you can't upload it to one repository the results you have to upload it to several places So for cross-building stuff, you know you need to build some things and then some other things depending on them And so on so you've got to have a repository behind it But it's not the real repository. It's got to be a local one And I wonder whether Jenkins helps with that or if It's still difficult Well, you can configure the jobs differently what I've done here for this pure part thing is My build steps here are just four or five shell commands. These are the shell commands for this job So I could have different batch scripts or whatever to Run build stuff in different environments But if the results of that build need to go into a particular repository depending on how I did the build Yeah, then you would define different uproads. So I just set up n repositories and then n different build rules Yeah, okay, maybe Yeah, I'm relying from IRC Ulrich Dangle says that a GRML uses Jenkins to automatically build CDs on every commit To their packages which is useful for changes like in each ram FS and there's also well github.com slash Maika Slash Jenkins a dash devian dash glue which helps creating and producing devian packages with Jenkins Yeah, I've looked at it But I had my own Implementation already written. So I keep using that one as it's really simple to build packages like this Hi, I used to work for smoothwall and recently we Moved all of the packages to use d package and We ended up using Jenkins as a replacement for want to build So with about 300 odd packages having a Jenkins job for every single one Built on high 386 and empty 64 using One of the plugins so Jenkins has loads of plugins which you can throw at this to Do different the same package in different environments and then those get put into a repository We're calling s build I think from From each Jenkins job and it's worked really well. It's helped with getting multiple developers working on same packages. So we have Commits going into git into an experimental branch and so on which then get uploaded into effectively an experimental Suite in the repository and then once it's got through code view using Garrett Which is a git code view tool that then ties into Jenkins and then makes the upload and change logs and puts it into the equivalent of unstable, I think it is so I'm not in the best position to talk about this because I don't work there anymore, but It is certainly possible to a lot of things and there are people out there doing doing those things I haven't used Jenkins, but I We we kind of use bill, but could you please Tell us the difference. I've never used billboard Does someone has used billboard or Jenkins that could tell us no No, well Yeah, be both does the same thing. So I thought I could see the Advantages well Thanks anyway, I was waiting a bit to Relate this because it seems to be starting a conversation But you know following a stream and starting a conversation on IRC can can have some luck a Intriguery says that the Ubuntu uses Jenkins to test these top grades at Jenkins dot qa dot Ubuntu dot com These top grades and installations. So he got the question on how does this compare to pew parts? So well the intergeri Replies no idea what kind of good or bad results are getting functional tests and that's as far as the conversation The pew parts test all packages So you would have to have a way to pass 30,000 results and having this for five distributions Then you have hundred thousand Jenkins jobs and that doesn't work. So I I don't see the way how to use pew parts with Jenkins as I understand that some of those Ubuntu upgrade tests are Installation of almost all the packages that can be co-installed together and then upgrading and seeing what what happens They're also testing of live images and all sorts of other things Yeah, that comes back. So you're saying you have to have a job per package that you want to build Because I mean the way that want to build and rebuild the work You just give it a list of jobs and it does the same thing for all of them So in my case I run app get build debt dash a s build architecture foo and they're all exactly the same That's the whole point But I don't want to have to define that individually 17,000 times once for each package in the archive. That seems like crazy talk Is there some way of automating that when they're all the same So that we can use this kind of nice infrastructure, which there are plugins for having job templates So you can just define the jobs from the template and create 30,000 templates if you want to I wouldn't do 30,000 But doing 200 is fine Yeah, a Wooler just says that there is one advantage of nkins of Jenkins is the ecosystem You have plenty of plugins available and it's somehow the standard tool for continuous integration So I guess this this is part of those plugins. Yeah one of these plugins for example passes these the test results here and displace them and There are plugins for all version control systems for several you test test suits for Notification for lots of things So where do what your logs end up? Are they going in a database or a massive directory or work or what the result logs of the bills? There's there on the file system No Where was I was a shell? So this is the pu can you read this? not really So the the configuration is this one XML file There's the workspace, which has the pu part source code after the build now and the builds directory has The different builds and then let's take the last one and the archive contains the produced files So it keeps the files in a workspace and then it for the one each build it keeps the locks there And can you drive it without the fancy interface? The without the without that web food stuff that I didn't really want. I mean, it's this should just run in the background Yeah, that's just for viewing the results. There's a command line interface as well, but I only use the web interface I really like the web interface which really surprised me, but it's very usable and The command line interface is also useful if you want to Run several Jenkins slaves and control them remotely than you use the command line interface So I think the reason this talk is about Jenkins and not about build bottom and Why? Everyone is so excited about it is because of the huge number of plugins. So it integrates with so many different tools. So Perhaps not so relevant for Most of the Debian work, but when you're doing development in the code repository and you've got branches and you've got multiple developers You can throw stuff like code coverage tools and so on at it and get nice Analysis and stuff going on and that's that's why that's what makes Jenkins so Good, you know I want one thing that it's a shame we can see in the demo was like the live output of the build Scrolling in the web interface. That's quite a Can you speak a bit louder, please? Oh, sorry the the scrolling. Oh my god the scrolling output of the compile So if you're making commits and then soon after looking at the build and Jenkins, you can see it as it breaks With some nice Ajax Yeah So I was showing you that now So does this have to run on the same machine as the builds are going on on or they can all the cheroots and builds beyond different hardware How does that all well does it have to be on the same machine as the kind of public web interface part for people to see the public? What runs where no you can run them drink and slave from other hosts and Then schedule jobs there Well the the talk is going on on IRC Well, he just told me No relaying needed. Sorry any other Do you hear me? Yeah, just not a question actually I really a lot Buying Standing as a lot louder. Okay. I'm really buying the IT whole girls Mentioned in this last slide about auto building DI So It will not happen if nobody does that, but I can't promise you We will have a lot better DI if we have a DI that bit that builds from our git So I would very much welcome someone volunteering for doing that Implementing Jenkins on one of our machines and building DI for every commit or something like this building the Udebs and Building the ISO images This this will be a really very important Improvement to the eye. I can't do that. I'm not able for doing that I have too much things to do elsewhere But if someone feels like implementing this he or she would be very very welcome Any more questions if there are no more questions Let's close this Thank you, Olga. Thank you