Re: Move builds off of Hudson master
On Tue, Jul 7, 2009 at 07:23, Paul Querna wrote: > On Thu, Jul 2, 2009 at 10:36 AM, Nigel Daley wrote: >> 4) We add a bunch more Ubuntu slaves to hudson.zones out of a pool of >> publicly IP'd yahoo.net machines my employer has for Hadoop related builds. > > I have concerns about intermingled infrastructures. > > I am mostly curious how adding more build slaves solves these > reliability problems, since they all seem to stem from builds taking > excessive amounts of time, freezing, or having whacky OOM issues. we currently have 166 builds competing to build on 6 build executors (I think). The majority of these are non Hadoop-related builds, so are actually competing for just 4 of those executors, 2 executors per machine on 2 VMs. There's a good chance many of the problems stem from load. > Won't adding more machines just mean more slaves get stuck in this mess? > > Isn't the right fix to fix projects to... for lack of a better word... suck? maybe _not_ suck? ;) Would you prefer if we gathered more evidence first? --j.
Hudson administrivia, build timeout
I'm installing the following plugins:
- Audit Trail plugin ('Keep a log of who performed particular Hudson
operations, such as configuring jobs', handy in our configuration with
so many users)
- Bugzilla Plugin ('This plugin integrates Bugzilla into Hudson', we use
bugzilla in SpamAssassin and I'm sure there are others)
- Warnings Plugin ('This plugin generates the trend report for compiler
warnings in the build log', looks pretty nifty!)
- and I'm going to re-try the Build Timeout plugin ('This plugin allows
you to automatically abort a build if it's taking too long').
We tried the build timeout before, I think, and it didn't help. But I
think some of the timeouts we're seeing now are due to broken tests on
some projects, and we've upgraded Hudson itself since the last try, so
it's worth a retry in my opinion.
I also checked the recent Hudson changelog, but nothing relevant has been
implemented that would fix build hangs.
Anyway, if your project has had problems with build hangs, please enable a
timeout on the "Configure" page. It's about halfway down, in the "Build
Environment" section -- tick the '[x] Abort the build if it's stuck'
tickbox and set 'Timeout minutes' to a sane upper limit.
If we run into builds of your projects timing out, we'll set this for you. ;)
--j.
Sling in Continuum instance on vmbuild
Hi, I see that the scm url of the Sling project isn't correct in Continuum [1], it use the incubator svn url. Do you continue to use it or do you use only Hudson that is described on the Sling page [2]? If Continuum isn't used for Sling, I'll can remove it. [1] http://vmbuild.apache.org/continuum/projectGroupSummary.action?projectGroupId=53 [2] http://sling.apache.org/site/project-information.html#ProjectInformation-ci Emmanuel
Sling in Continuum instance on vmbuild
Hi, I see that the scm url of the Sling project isn't correct in Continuum [1], it use the incubator svn url. Do you continue to use it or do you use only Hudson that is described on the Sling page [2]? If Continuum isn't used for Sling, I'll can remove it. [1] http://vmbuild.apache.org/continuum/projectGroupSummary.action?projectGroupId=53 [2] http://sling.apache.org/site/project-information.html#ProjectInformation-ci Emmanuel
change Hudson to use LDAP for web auth
currently, Hudson.zones.apache.org has two user auth dbs: 1. a Tomcat tomcat-users.xml file to authenticate Hudson users over HTTP 2. /etc/passwd, to auth users logging in via SSH Now, #2 should probably not yet be changed to use the ASF's LDAP, as we restrict Hudson changes to PMC members, rather than all committers. But #1 could be changed to do this, since there's an additional layer of authorization imposed by the Hudson configuration. it'd be great to do this since it'd remove an entire set of user/passwords for us to maintain. We could authenticate their logins via LDAP, but restrict changes to the authorized list in that Hudson config. Looking at http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JNDIRealm , this looks pretty feasible. Infra - is this viable? can we set this up? has anyone got experience using JNDIRealm with LDAP? does it work? --j.
Re: Sling in Continuum instance on vmbuild
Hi, we've moved to Hudson - so you can kill the Continuum configuration (I thought we already did this) Regards Carsten Emmanuel Venisse wrote: > Hi, > > I see that the scm url of the Sling project isn't correct in Continuum [1], > it use the incubator svn url. > Do you continue to use it or do you use only Hudson that is described on the > Sling page [2]? > > If Continuum isn't used for Sling, I'll can remove it. > > [1] > http://vmbuild.apache.org/continuum/projectGroupSummary.action?projectGroupId=53 > [2] > http://sling.apache.org/site/project-information.html#ProjectInformation-ci > > Emmanuel > -- Carsten Ziegeler cziege...@apache.org
Re: Sling in Continuum instance on vmbuild
Ok, I'll do it. Thanks Emmanuel On Tue, Jul 7, 2009 at 1:51 PM, Carsten Ziegeler wrote: > Hi, > > we've moved to Hudson - so you can kill the Continuum configuration (I > thought we already did this) > > Regards > Carsten > > Emmanuel Venisse wrote: > > Hi, > > > > I see that the scm url of the Sling project isn't correct in Continuum > [1], > > it use the incubator svn url. > > Do you continue to use it or do you use only Hudson that is described on > the > > Sling page [2]? > > > > If Continuum isn't used for Sling, I'll can remove it. > > > > [1] > > > http://vmbuild.apache.org/continuum/projectGroupSummary.action?projectGroupId=53 > > [2] > > > http://sling.apache.org/site/project-information.html#ProjectInformation-ci > > > > Emmanuel > > > > > -- > Carsten Ziegeler > cziege...@apache.org >
Wink distribution failed to deploy to https://repository.apache.org
HI, I need your assistance with the following issue: I am a member in Wink project (apache incubator) ... We have configured Hudson build to deploy Wink artifacts to https://repository.apache.org/content/repositories/snapshots Yesterday all worked fine.. but today all build failed with 401 while trying to deploy to https://repository.apache.org/content/repositories/snapshots --martin
