Re: purging of old job artifacts
> On Apr 25, 2018, at 3:04 AM, Chris Lambertus wrote: > > The top-level list of jobs is available here: https://paste.apache.org/r37e > That list includes: • CXF-2.0-deploy • CXF-2.0.x-JDK15 • CXF-2.1-deploy • CXF-2.1.x-JDK15 Those jobs were deleted from Jenkins years ago.They aren’t available from the front end at all.Is it possible that more of the directories on the list don’t have jobs associated with them anymore and could just be wiped out? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Welcome to the builds list!
Is there any particular reason that the index page at ci.apache.org be updated to add sections for Hudson and Continuum? Would that solve everyones issues? Or maybe push buildbot stuff into ci.apache.org/buildbot, have ci.apache.org/hudson and continuum. There "index" at ci.apache.org would still mention and point to buildbot stuff, so existing blogs and stuff would still be "accurate". I'm failing to see what all the hub-bub is about. Dan On Thu April 23 2009 1:22:49 am Nigel Daley wrote: > On Apr 16, 2009, at 2:25 AM, Gavin wrote: > >> -Original Message- > >> From: bdelacre...@gmail.com [mailto:bdelacre...@gmail.com] On > >> Behalf Of > >> Bertrand Delacretaz > >> Sent: Wednesday, 15 April 2009 6:28 PM > >> To: builds@apache.org > >> Subject: Re: Welcome to the builds list! > >> > >> On Fri, Apr 10, 2009 at 1:13 PM, Gavin > >> > >> wrote: > >>>> -Original Message- > >>>> From: Nigel Daley [mailto:nda...@yahoo-inc.com] > >>>> Also, Gavin can we have ci.apache.org go to a page that > >>>> points to > >> > >> the > >> > >>>> 3 CI choices that Apache projects have: Buildbot, Continuum, and > >> > >> Hudson? > >> > >>> Absolutely, ci.apache.org was created a couple of months back whilst > >> > >> testing > >> > >>> buildbot and before this amalgamation of CIs list was thought > >>> about. It > >>> makes sense so I will do that soon, thanks for the suggestion > >> > >> It might be good to mention this list there as well. > >> -Bertrand > > > > Yep good plan. > > > > A slight change to name to use as the main builds area to go to, > > ci.apache.org has been advertised/blogged/tweeted/whatever as > > belonging to > > the buildbot setup. I think it is too late now to move that to another > > domain. Either way, a new name was needed for either buildbot usage > > or the > > main builds area (landing page?). > > > > So, to keep inline with this list name etc, and Wendy proposed on > > IRC that > > builds.apache.org would be a better fit for the new area. > > > > If there are no objections I'd like to ask infra if they could set > > that up > > for us? (cc:d) > > > > Gav... > > Hmm, not crazy about this, but ok. Not sure why you didn't go with > buildbot.apache.org. Taking ci.apache.org seems a little over reaching. > > Nige -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Welcome to the builds list!
Gav, Why should that page be generated by buildbot? Couldn't that one index.html just be a static page checked into SVN someplace and served directly? Dan On Thu April 23 2009 9:52:09 am Gavin wrote: > > -Original Message- > > From: Daniel Kulp [mailto:dk...@apache.org] > > Sent: Thursday, 23 April 2009 11:25 PM > > To: infrastruct...@apache.org > > Cc: Nigel Daley; Gavin; builds@apache.org > > Subject: Re: Welcome to the builds list! > > > > > > Is there any particular reason that the index page at ci.apache.org be > > updated > > to add sections for Hudson and Continuum? Would that solve everyones > > issues? > > I reckon I can do that yes. It is generated with twisted and buried in > buildbot somewhere but I'll look at doing that. > > To be clear, I'll move the current index page that shows the default > 'Welcome to Buildbot' to ci.apache.org/buildbot and replace it with a new > page that lists the other two CIs. > > As much as it seems strange hacking Buildbot code to advertise other CI > servers on it, it's what people want so hey ho. > > Gav... > > > Or maybe push buildbot stuff into ci.apache.org/buildbot, have > > ci.apache.org/hudson and continuum. There "index" at ci.apache.org > > would still mention and point to buildbot stuff, so existing blogs and > > stuff would > > still be "accurate". > > > > I'm failing to see what all the hub-bub is about. > > > > Dan > > > > On Thu April 23 2009 1:22:49 am Nigel Daley wrote: > > > On Apr 16, 2009, at 2:25 AM, Gavin wrote: > > > >> -Original Message- > > > >> From: bdelacre...@gmail.com [mailto:bdelacre...@gmail.com] On > > > >> Behalf Of > > > >> Bertrand Delacretaz > > > >> Sent: Wednesday, 15 April 2009 6:28 PM > > > >> To: builds@apache.org > > > >> Subject: Re: Welcome to the builds list! > > > >> > > > >> On Fri, Apr 10, 2009 at 1:13 PM, Gavin > > > >> > > > >> wrote: > > > >>>> -Original Message- > > > >>>> From: Nigel Daley [mailto:nda...@yahoo-inc.com] > > > >>>> Also, Gavin can we have ci.apache.org go to a page that > > > >>>> points to > > > >> > > > >> the > > > >> > > > >>>> 3 CI choices that Apache projects have: Buildbot, Continuum, and > > > >> > > > >> Hudson? > > > >> > > > >>> Absolutely, ci.apache.org was created a couple of months back > > > >>> whilst > > > >> > > > >> testing > > > >> > > > >>> buildbot and before this amalgamation of CIs list was thought > > > >>> about. It > > > >>> makes sense so I will do that soon, thanks for the suggestion > > > >> > > > >> It might be good to mention this list there as well. > > > >> -Bertrand > > > > > > > > Yep good plan. > > > > > > > > A slight change to name to use as the main builds area to go to, > > > > ci.apache.org has been advertised/blogged/tweeted/whatever as > > > > belonging to > > > > the buildbot setup. I think it is too late now to move that to > > > > another domain. Either way, a new name was needed for either buildbot > > > > usage or the > > > > main builds area (landing page?). > > > > > > > > So, to keep inline with this list name etc, and Wendy proposed on > > > > IRC that > > > > builds.apache.org would be a better fit for the new area. > > > > > > > > If there are no objections I'd like to ask infra if they could set > > > > that up > > > > for us? (cc:d) > > > > > > > > Gav... > > > > > > Hmm, not crazy about this, but ok. Not sure why you didn't go with > > > buildbot.apache.org. Taking ci.apache.org seems a little over > > > reaching. > > > > > > Nige > > > > -- > > Daniel Kulp > > dk...@apache.org > > http://www.dankulp.com/blog > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG. > > Version: 7.5.557 / Virus Database: 270.12.2/2074 - Release Date: > > 4/22/2009 8:49 AM -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Sonar installation at Apache
The Sonar folks have been pretty good about adding other projects to their instance. Several Apache projects already have stuff there: http://nemo.sonar.codehaus.org/ That said, I'd still like it "in house" where we'd be able to have some admin accounts on it to setup/configure various things. Dan On Wed June 3 2009 11:09:06 am Jukka Zitting wrote: > Hi, > > Sonar [1] is a nice tool for reporting various source code metrics on > different projects. It would be cool to have a Sonar installation also > at Apache. I can volunteer to set it up if we have spare capacity on > some server. > > [1] http://sonar.codehaus.org/ > > BR, > > Jukka Zitting -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Sonar installation at Apache
On Wed June 3 2009 11:40:53 am Jukka Zitting wrote: > Hi, > > On Wed, Jun 3, 2009 at 5:33 PM, Daniel Kulp wrote: > > The Sonar folks have been pretty good about adding other projects to > > their instance. Several Apache projects already have stuff there: > > > > http://nemo.sonar.codehaus.org/ > > Oh, that's pretty cool! Though it looks like they aren't doing very > frequent builds. Supposedly once a week they try to do a build, but results are only updated if the build actually succeeds. (compiles correctly) Dan > > That said, I'd still like it "in house" where we'd be able to have some > > admin accounts on it to setup/configure various things. > > Agreed. It would also be nice to integrate it with Hudson and our > other CI tools. > > BR, > > Jukka Zitting -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Hudson machine utilization
On Mon November 16 2009 11:23:42 am Nigel Daley wrote: > I think anything currently *unbound* gets run on the master since it's > the only 'slave' that isn't reserved for tied jobs (last I looked). So would it make sense to "untick" that tick box for vesta and/or minerva? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: rsync daemon on hudson slave?
On Thursday 03 March 2011 8:33:21 AM Jukka Zitting wrote: > Hi, > > On Thu, Mar 3, 2011 at 2:30 PM, Ulrich Stärk wrote: > > The only thing that seems reasonable apart from having an rsync daemon is > > doing a recursive wget on the generated site every hour or so. This will > > however fetch all 4000 files and I don't know how much load it puts on > > Jenkins. Is this OK? > > Doesn't sound like a very good approach. > > The Apache CMS setup running on Buildbot simply commits the generated > site to svn from where it's picked up by the public web servers. I > guess a similar setup could be done also with Maven site builds > running in Hudson. That's kind of what I was thinking. If buildbot has creds stored someplace to be able to run "svn commit", could one of the Jenkins build slaves (doesn't need to be all of them) also have svn installed with stored creds? I don't even think it needs to be built into Jenkins itself. If svn is installed, the build itself (exec plugin or something) could run "svn commit - m 'Web site update'" or something. I think a bunch of projects might be willing to flip to more of a svnpubsub publish if we could get Jenkins builds to do it. That could reduce some load on the rsyncs on p.a.o. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: rsync daemon on hudson slave?
On Thursday 03 March 2011 9:35:00 AM Ulrich Stärk wrote: > I always had the impression that stored credentials, be it cached SVN > credentials or private keys in people's home dirs, was strongly > discouraged. I didn't say in the home dirs on p.a.o. I'm talking about a fairly locked down build slave that really only has a single "user" account: the jenkins build account.It would be a unique user id (like buildbots) that can be locked down in svn to only be able to commit to very particular locations (like the exported site area, not to any code locations, not even the site source locations). Basically, buildbot is setup like this, I'm just asking what it would take to get a Jenkins slave to be setup as well. Dan > Otherwise I could just have requested an account on vesta and > copied the stuff over to people with a private key stored in my home dir > on people (see my mail from 2011/02/02). This is why I started this whole > thread in the first place... > > Uli > > On 03.03.2011 15:23, Daniel Kulp wrote: > > On Thursday 03 March 2011 8:33:21 AM Jukka Zitting wrote: > >> Hi, > >> > >> On Thu, Mar 3, 2011 at 2:30 PM, Ulrich Stärk wrote: > >>> The only thing that seems reasonable apart from having an rsync daemon > >>> is doing a recursive wget on the generated site every hour or so. This > >>> will however fetch all 4000 files and I don't know how much load it > >>> puts on Jenkins. Is this OK? > >> > >> Doesn't sound like a very good approach. > >> > >> The Apache CMS setup running on Buildbot simply commits the generated > >> site to svn from where it's picked up by the public web servers. I > >> guess a similar setup could be done also with Maven site builds > >> running in Hudson. > > > > That's kind of what I was thinking. If buildbot has creds stored > > someplace to be able to run "svn commit", could one of the Jenkins build > > slaves (doesn't need to be all of them) also have svn installed with > > stored creds? > > > > I don't even think it needs to be built into Jenkins itself. If svn is > > installed, the build itself (exec plugin or something) could run "svn > > commit - m 'Web site update'" or something. > > > > I think a bunch of projects might be willing to flip to more of a > > svnpubsub publish if we could get Jenkins builds to do it. That could > > reduce some load on the rsyncs on p.a.o. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: rsync daemon on hudson slave?
On Thursday 03 March 2011 10:20:37 AM Joe Schaefer wrote: > Why doesn't someone roll up their sleeves and teach maven to > build things in a way that's compatible with the CMS builds? Why doesn't someone roll up their sleeves and teach the CMS to build things in a way that's compatible with the way Maven builds things? :-) Dan > > > > - Original Message > > > From: Ulrich Stärk > > To: builds@apache.org > > Sent: Thu, March 3, 2011 10:15:13 AM > > Subject: Re: rsync daemon on hudson slave? > > > > Yet another tool just for some special aspect of our builds... > > > > Uli > > > > On 03.03.2011 16:00, Jukka Zitting wrote: > > > Hi, > > > > > > 2011/3/3 Niklas Gustavsson : > > >> Not sure how we would restrict anyone with access to Jenkins from > > >> > > >> running any job on such a slave. We would need to find a way for > > >> only > > >> > > >> Jenkins admins to tie jobs to that slave. > > > > > > One alternative would be to run such site build jobs only on Buildbot, > > > as there the commit account setup has already been done. AFAIUI the > > > site builds are fairly straightforward, so there should be no need for > > > all the extra features Jenkins has over Buildbot. > > > > > > BR, > > > > > > Jukka Zitting -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Timeout limit doesn't work
On Dec 6, 2013, at 5:14 PM, Dave Brondsema wrote: Looks like we still have a problem, and the ubuntu backlog has been at 25+ jobs > for 3 days. A specific example is > https://builds.apache.org/job/CXF-2.7-deploy/231/ currently running for 7hr so > far. It has an absolute timeout of 187 minutes. I'm sure there are more > cases, > but that was the first I found. Personally, I think all of the unbuntu boxes should just be rebooted and see if a fresh start would help. The builds that are succeeding are taking almost double the normal amount of time which leads me think there are all kinds of stuck processes or something consuming resources. Dan > > -Dave > > > On 11/18/13 6:48 PM, Gavin McDonald wrote: >> Olivier Lamy upgraded the Jenkins instance, he seemed to recall a fix for >> this. >> >> Let's see how it runs now. >> >> Thanks >> >> Gav... >> >>> -Original Message- >>> From: Dave Brondsema [mailto:d...@brondsema.net] >>> Sent: Tuesday, 19 November 2013 8:19 AM >>> To: builds@apache.org >>> Subject: Re: Timeout limit doesn't work >>> >>> On 11/14/13 2:14 PM, Lukasz Lenart wrote: >>>> Why the Absolute Timeout limit doesn't work? For example, the build >>>> [1] has timeout limit set to 187 minutes, but that job [1] is running >>>> 15h as for now and blocks other builds :\ >>>> >>>> https://builds.apache.org/job/CXF-2.7-deploy/configure >>>> https://builds.apache.org/job/CXF-2.7-deploy/219/ >>>> >>> >>> I'm seeing this as a real problem, too. Looking at jobs currently running >>> on >>> the ubuntu hosts, these seem very very long (and still going, as of this >>> writing): >>> >>> https://builds.apache.org/job/Camel.trunk.notest/2041/ >>> 16hr, but timeout is 180 min >>> >>> https://builds.apache.org/job/Qpid-Java-Java-MMS-TestMatrix/1473/ >>> 11hr, but timeout is 180 min >>> >>> https://builds.apache.org/job/cloudstack-master-maven/3348/ >>> 6hr, timeout is elastic 150% >>> >>> https://builds.apache.org/job/Camel.trunk.fulltest/1615/ >>> 11hr, but timeout is 365 min >>> >>> https://builds.apache.org/job/river-qa-refactor-jdk7/113/ >>> 1.5hr (previous took 16hr), timeout is 2253 min -- really? >>> >>> https://builds.apache.org/job/Camel.2.12.x.fulltest/102/ >>> 11hr, but timeout is 365 min >>> >>> This ends up backlogging other jobs: >>> https://builds.apache.org/label/ubuntu/load-statistics?type=hour >>> >>> -- >>> Dave Brondsema : d...@brondsema.net >>> http://www.brondsema.net : personal >>> http://www.splike.com : programming >>> <>< >> > > > > -- > Dave Brondsema : d...@brondsema.net > http://www.brondsema.net : personal > http://www.splike.com : programming > <>< -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Commented] (BUILDS-85) Could not generate DH keypair / peer not authenticated
[ https://issues.apache.org/jira/browse/BUILDS-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622160#comment-14622160 ] Daniel Kulp commented on BUILDS-85: --- Do the Jenkins slaves have a toolchains.xml file that would point to the various JDK's that are installed so that we could use toolchains for Jenkins builds? > Could not generate DH keypair / peer not authenticated > --- > > Key: BUILDS-85 > URL: https://issues.apache.org/jira/browse/BUILDS-85 > Project: Infra Build Platform > Issue Type: Bug > Components: Jenkins >Reporter: Andreas Lehmkühler >Assignee: Geoffrey Corey > Attachments: SSLPoke.java > > > We're getting this since june 10th: > [INFO] --- maven-deploy-plugin:2.6:deploy (default-deploy) @ pdfbox-parent --- > Downloading:https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/1.8.10-SNAPSHOT/maven-metadata.xml > [WARNING] Could not transfer metadata > org.apache.pdfbox:pdfbox-parent:1.8.10-SNAPSHOT/maven-metadata.xml from/to > apache.snapshots.https > (https://repository.apache.org/content/repositories/snapshots): Error > transferring file: java.lang.RuntimeException: Could not generate DH keypair > and this: > [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ pdfbox-parent > --- > Downloading:https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/2.0.0-SNAPSHOT/maven-metadata.xml > [WARNING] Could not transfer metadata > org.apache.pdfbox:pdfbox-parent:2.0.0-SNAPSHOT/maven-metadata.xml from/to > apache.snapshots.https > (https://repository.apache.org/content/repositories/snapshots): peer not > authenticated > The issue seems to be jdk related as only those builds using java 1.6.0_37 > (unlimited security) are failing. I've reconfigured the trunk build to use > java 7 and everything works fine, as well as our jdk7 based branch build. > Any ideas? Maybe a plugin update which doesn't work with java6? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
