[JIRA] (JENKINS-13707) Job disables itself during excecution
Sebastian Laag created JENKINS-13707:
Summary: Job disables itself during excecution
Key: JENKINS-13707
URL: https://issues.jenkins-ci.org/browse/JENKINS-13707
Project: Jenkins
Issue Type: Bug
Components: core
Reporter: Sebastian Laag
Jenkins Version: 1.462
Since yesterday one of our Jenkins jobs disables itself. With a bit testing i
could figure out, that the environment variables, which are used in the svn
url, cause the error. If i remove them, everything works fine.
We also use a seperate Jenkins with Version 1.456 and have no problems with
environment variables in svn urls.
Summary (with Version 1.462):
https://svn.example.org/svn/$VARIABLE -> After starting the build, the job will
be disabled, but excecuted as usual
https://svn.example.org/svn/${VARIABLE} -> After starting the build, the job
will be disabled, but excecuted as usual
https://svn.example.org/svn/branch -> Everything works fine
Do you need any further information?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13707) Job disables itself during excecution, when using environment variables in repository url
[
https://issues.jenkins-ci.org/browse/JENKINS-13707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Laag updated JENKINS-13707:
-
Summary: Job disables itself during excecution, when using environment
variables in repository url (was: Job disables itself during excecution)
> Job disables itself during excecution, when using environment variables in
> repository url
> -
>
> Key: JENKINS-13707
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13707
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Reporter: Sebastian Laag
>
> Jenkins Version: 1.462
> Since yesterday one of our Jenkins jobs disables itself. With a bit testing i
> could figure out, that the environment variables, which are used in the svn
> url, cause the error. If i remove them, everything works fine.
> We also use a seperate Jenkins with Version 1.456 and have no problems with
> environment variables in svn urls.
> Summary (with Version 1.462):
> https://svn.example.org/svn/$VARIABLE -> After starting the build, the job
> will be disabled, but excecuted as usual
> https://svn.example.org/svn/${VARIABLE} -> After starting the build, the job
> will be disabled, but excecuted as usual
> https://svn.example.org/svn/branch -> Everything works fine
> Do you need any further information?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13707) Job disables itself during execution, when using environment variables in repository url
[
https://issues.jenkins-ci.org/browse/JENKINS-13707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Laag updated JENKINS-13707:
-
Summary: Job disables itself during execution, when using environment
variables in repository url (was: Job disables itself during excecution, when
using environment variables in repository url)
Description:
Jenkins Version: 1.462
Since yesterday one of our Jenkins jobs disables itself. With a bit testing i
could figure out, that the environment variables, which are used in the svn
url, cause the error. If i remove them, everything works fine.
We also use a seperate Jenkins with Version 1.456 and have no problems with
environment variables in svn urls.
Summary (with Version 1.462):
https://svn.example.org/svn/$VARIABLE -> After starting the build, the job will
be disabled, but executed as usual
https://svn.example.org/svn/${VARIABLE} -> After starting the build, the job
will be disabled, but executed as usual
https://svn.example.org/svn/branch -> Everything works fine
Do you need any further information?
was:
Jenkins Version: 1.462
Since yesterday one of our Jenkins jobs disables itself. With a bit testing i
could figure out, that the environment variables, which are used in the svn
url, cause the error. If i remove them, everything works fine.
We also use a seperate Jenkins with Version 1.456 and have no problems with
environment variables in svn urls.
Summary (with Version 1.462):
https://svn.example.org/svn/$VARIABLE -> After starting the build, the job will
be disabled, but excecuted as usual
https://svn.example.org/svn/${VARIABLE} -> After starting the build, the job
will be disabled, but excecuted as usual
https://svn.example.org/svn/branch -> Everything works fine
Do you need any further information?
> Job disables itself during execution, when using environment variables in
> repository url
>
>
> Key: JENKINS-13707
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13707
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Reporter: Sebastian Laag
>
> Jenkins Version: 1.462
> Since yesterday one of our Jenkins jobs disables itself. With a bit testing i
> could figure out, that the environment variables, which are used in the svn
> url, cause the error. If i remove them, everything works fine.
> We also use a seperate Jenkins with Version 1.456 and have no problems with
> environment variables in svn urls.
> Summary (with Version 1.462):
> https://svn.example.org/svn/$VARIABLE -> After starting the build, the job
> will be disabled, but executed as usual
> https://svn.example.org/svn/${VARIABLE} -> After starting the build, the job
> will be disabled, but executed as usual
> https://svn.example.org/svn/branch -> Everything works fine
> Do you need any further information?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13698) Error 500 on static assets with 1.463-1.1 rpm
[
https://issues.jenkins-ci.org/browse/JENKINS-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162528#comment-162528
]
asgeirn commented on JENKINS-13698:
---
Could you try the latest 1.12 version that Kohsuke just made? It appears to
have addressed this.
> Error 500 on static assets with 1.463-1.1 rpm
> -
>
> Key: JENKINS-13698
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13698
> Project: Jenkins
> Issue Type: Bug
> Components: greenballs
>Reporter: Mark Doliner
>Assignee: asgeirn
>
> I yum updated to the jenkins-1.463-1.1 rpm from
> http://pkg.jenkins-ci.org/redhat/ repository today at noon PDT. I'm running
> on CentOS 5.8 with java 1.6.0.
> Since then, logged out users get the following error response for various
> static files (https://server:8443/static/5d0888f6/images/title.png, for
> example):
> {noformat}
> May 7, 2012 1:39:38 PM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.NullPointerException
> at
> hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:50)
> at
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
> at
> hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
> at
> hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at
> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
> at
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
> at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(T
[JIRA] (JENKINS-13149) SCM Poll causing non-stop builds
[ https://issues.jenkins-ci.org/browse/JENKINS-13149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162529#comment-162529 ] Mirela B commented on JENKINS-13149: I have the same issue with the latest version of jenkins(1.462) and perforce plugin(1.3.1) pooling log: No changes found. Done. Took 5 min 42 sec Changes found > SCM Poll causing non-stop builds > > > Key: JENKINS-13149 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13149 > Project: Jenkins > Issue Type: Bug > Components: mercurial >Affects Versions: current > Environment: HG 2.0.1 / Jenkins 1.456 / Plugin 1.3.8 >Reporter: Justin Rovang >Assignee: Kohsuke Kawaguchi >Priority: Critical > > I hate to bring such conflicting information into a bug report but I'm at a > loss on this! > This only happens for this one repo - I've deleted and re-created it, and > setup from scratch with no joy. > HG SCM Poll log insists it's finding changes and is firing a build off of > 'Dependent changes detected'. > Started on Mar 19, 2012 11:00:24 PM > [src] $ hg pull --rev default > pulling from /var/hg/repos/mpl > no changes found > [src] $ hg log --style > /var/lib/jenkins/jobs/mpl/workspace/tmp2857899180971434423style --branch > default --no-merges --prune 9c80c470fa3ef8d89c2352c08babb3f466b9aa24 > id:5b02d29a94c43648da2eb0a16f12c2e42eb46c87 > files:build.xml: > Dependent changes detected > Done. Took 0.21 sec > Changes found > There's no open/un-merged heads in the repo either: > default 141:9c80c470fa3e > If I downgrade to 1.3.7, it works fine (seems to run a different technique) > HG SCM Poll log from 1.3.7: > Started on Mar 19, 2012 11:11:14 PM > [src] $ hg incoming --style > /var/lib/jenkins/jobs/mpl/workspace/tmp1826463261407545325style --no-merges > --rev default --newest-first > comparing with /var/hg/repos/mpl > no changes found > Done. Took 53 ms > No changes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6747) Support concurrent runs of matrix builds
[ https://issues.jenkins-ci.org/browse/JENKINS-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162530#comment-162530 ] Sven Appenrodt commented on JENKINS-6747: - OK - seems, this problem ist not popular so i tested several changes in the configuration. Seems it is a display-problem only. If you browse to the job-configuration, open all config.xml files (also in all!! sub folders) and change the entry: false to 'true' then you can use parallel builds with this kind of job, after reloading the configuration. Maybe using this knowlege, this bug can be handled, so the configurations can be saved in a official way... > Support concurrent runs of matrix builds > > > Key: JENKINS-6747 > URL: https://issues.jenkins-ci.org/browse/JENKINS-6747 > Project: Jenkins > Issue Type: Improvement > Components: concurrent-build >Reporter: Eric Smalling >Assignee: Kohsuke Kawaguchi > > I'd like to be able to run matrix builds in parallel, currently that option > doesn't appear in the configuration so I'm assuming it's not implemented yet. > :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162531#comment-162531 ] Michael Clarke commented on JENKINS-13227: -- Yes and No. The modified plugin seems to pick up changes but then hangs after parsing some of them. I've not been able to narrow down what's causing this but I suspect it's a dodgy regular expression resulting in a field matching repeatedly and therefore going into a loop. I'll upload my changes as soon as I've fixed this issue so that you can try them. > CVS plugin 2.1 does not detect changes > -- > > Key: JENKINS-13227 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13227 > Project: Jenkins > Issue Type: Bug > Components: cvs >Reporter: Guillaume Bilodeau >Assignee: Michael Clarke >Priority: Critical > Labels: cvs > Attachments: rlog.txt > > > As presented in the user group: > https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4 > We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS > repository for a few weeks now, without any problems. The CVS plugin (v1.6) > was using the local cvsnt install. > We've since upgraded the CVS plugin to version 2.1 (by manually pinning the > plugin) and since then, CVS changes are not detected. The CVS polling log is > triggered properly, tons of "cvs rlog" instructions are sent, but at the end > "No changes" is displayed. > Using CVS plugin 1.6 the cvs polling command looked like this (executed at > 5:26:21 PM EDT): > cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D > "Thursday, March 22, 2012 9:26:21 PM UTC" > Using CVS plugin 2.1, the last cvs checkout command looked like this > (executed at 11:56:16 AM EDT): > cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 > 11:56:16 EDT -d portailInt portailInt > We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-3121) Hudson returns http 405 when parameterized option is checked
[
https://issues.jenkins-ci.org/browse/JENKINS-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162532#comment-162532
]
Qian Qiao commented on JENKINS-3121:
I'm not sure using GET requests on /job/x/buildWithParameters is even a proper
workaround, since it means that the "build" link on the left nav bar is
completely useless, since it always points /job/x/build
The fact is that 405 will cause Jenkins' UI to be unusable on RPs that generate
their own error page, and I don't think there's a valid reason to use 405
instead of 302 here.
I think this issue deserves to be re-opened and given more thought.
> Hudson returns http 405 when parameterized option is checked
>
>
> Key: JENKINS-3121
> URL: https://issues.jenkins-ci.org/browse/JENKINS-3121
> Project: Jenkins
> Issue Type: Bug
> Components: parameterized-trigger
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: dbowler_cn
>Assignee: huybrechts
>
> When the "parameterized" option is checked within a build, Hudson is
> returning a
> HTTP 405.
> This was using Hudson 1.285
> This is a problem when using Hudson behind a proxy as the proxy will return
> only
> the HTTP 405 response code.
> $ curl -v http://cu009.cubit.ibitdev.com:8080/job/test_params/build?delay=0sec
> * About to connect() to cu009.cubit.ibitdev.com port 8080 (#0)
> * Trying 208.87.8.211... connected
> * Connected to cu009.cubit.ibitdev.com (208.87.8.211) port 8080 (#0)
> > GET /job/test_params/build?delay=0sec HTTP/1.1
> > User-Agent: curl/7.16.3 (i686-pc-cygwin) libcurl/7.16.3 OpenSSL/0.9.8i
> > zlib/1.
> 2.3 libssh2/0.15-CVS
> > Host: cu009.cubit.ibitdev.com:8080
> > Accept: */*
> >
> < HTTP/1.1 405 Method Not Allowed
> < Server: Winstone Servlet Engine v0.9.10
> < Expires: 0
> < Content-Type: text/html;charset=UTF-8
> < Connection: Close
> < Date: Mon, 23 Feb 2009 20:08:45 GMT
> < X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
> < Set-Cookie: JSESSIONID=56cb51b13ed79bbc1c91c45fb397022f; Path=/
> <
>
> Hudson href="/static/0d
> 946710/css/style.css"> href="/stati
> c/0d946710/css/color.css"> rel="shor
> tcut icon" href="/static/0d946710/favicon.ico">var
> isRunAsTest=fa
> lse; type="text/java
> script"> type="text/j
> avascript"> type="tex
> t/javascript"> src="/static/0d946710/scripts/yui/yahoo/yahoo-min
> .js"> src="/static/0d946710/scripts/yui/dom/dom-min.js"> > >src="/static/0d946710/scripts/yui/event/event-min.js"> src="/static/0d946710/scripts/yui/animation/animation-min.js"> s
> rc="/static/0d946710/scripts/yui/container/container-min.js"> sr
> c="/static/0d946710/scripts/yui/connection/connection-min.js"> s
> rc="/static/0d946710/scripts/yui/autocomplete/autocomplete-min.js"> ipt src="/static/0d946710/scripts/yui/menu/menu-min.js"> src="/s
> tatic/0d946710/scripts/yui/element/element-beta-min.js"> src="/s
> tatic/0d946710/scripts/yui/button/button-min.js"> src="/static/0
> d946710/scripts/yui/dragdrop/dragdrop-min.js"> src="/static/0d94
> 6710/scripts/hudson-behavior.js" type="text/javascript"> type="tex
> t/css" rel="stylesheet"
> href="/static/0d946710/scripts/yui/container/assets/cont
> ainer.css"> href="/static/0d946710/
> scripts/yui/assets/skins/sam/skin.css"> rel="stylesh
> eet"
> href="/static/0d946710/scripts/yui/button/assets/skins/sam/button.css"> nk> href="/static/0d946710/scripts/yui/men
> u/assets/skins/sam/menu.css"> type="application/opensearchdescriptio
> n+xml" rel="search" title="Hudson" href="/opensearch.xml"> content="
> INDEX,NOFOLLOW" name="ROBOTS"> rel="alter
> nate" title="Hudson:test_params (all builds)" href="rssAll"> type="a
> pplication/rss+xml" rel="alternate" title="Hudson:test_params (all builds)
> (RSS
> 2.0)" href="rssAll?flavor=rss20"> rel="al
> ternate" title="Hudson:test_params (failed builds)"
> href="rssFailed"> k type="application/rss+xml" rel="alternate" title="Hudson:test_params
> (failed b
> uilds) (RSS 2.0)" href="rssFailed?flavor=rss20"> type="application/r
> ss+xml" rel="alternate" title="Hudson:test_params (changelog)"
> href="rssChangelo
> g"> title="Hudson:test_pa
> rams (changelog) (RSS 2.0)"
> href="rssChangelog?flavor=rss20"> class="yui-skin-sam">Skip to
> content a> id="header"> > >cellpadding="0" c
> ellspacing="0"> href="/"> g src="/static/0d946710/images/title.png" alt="title"> style="
> vertical-align: middle; text-align: right; padding-right: 1em;"> style="pos
> ition:relative;" class="no-json" action="/job/test_params/search/"
> method="get"
> name="search"> id="search-box-sizer"> iv> value="search"
> id="search-box" name="q">A href="http://hudson.gotdns.com/wiki/displ
> ay/HUDSON/Search+Box"> alt="hel
> p for search"> id="search-box-completion">createSear
> chBox("/job/test_params/search/"); id="login-field
> "
[JIRA] (JENKINS-13241) Artifact archiving from remote slave fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162533#comment-162533 ] RITUL KAKATI commented on JENKINS-13241: Hi, I am also getting the same error with AIX and HP-UX (IA64N); but for windows, Solaris (sparc and x86-64) and Linux (IBM System z) it is working fine. I am using Jenkins ver. 1.459. [htmlpublisher] Archiving HTML reports... [htmlpublisher] Archiving at BUILD level /WM/TESTSRV/testenv/deployer/deployer_bvt/ALF/reports to /opt/hudson/jobs/deployer-setup-test-aixwm9t/builds/2012-05-07_15-34-54/htmlreports/HTML_Report FATAL: HTML Publisher failure hudson.util.IOException2: java.lang.UnsupportedOperationException at hudson.FilePath.copyRecursiveTo(FilePath.java:1745) at hudson.FilePath.copyRecursiveTo(FilePath.java:1637) at htmlpublisher.HtmlPublisher.perform(HtmlPublisher.java:217) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:680) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627) at hudson.model.Run.run(Run.java:1438) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.util.concurrent.ExecutionException: java.lang.UnsupportedOperationException at hudson.remoting.Channel$3.adapt(Channel.java:679) at hudson.remoting.Channel$3.adapt(Channel.java:674) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55) at hudson.FilePath.copyRecursiveTo(FilePath.java:1743) ... 12 more Caused by: java.lang.UnsupportedOperationException at hudson.os.PosixAPI$1.getCurrentWorkingDirectory(PosixAPI.java:59) at org.jruby.ext.posix.util.ExecIt.run(ExecIt.java:59) at org.jruby.ext.posix.util.ExecIt.runAndWait(ExecIt.java:51) at org.jruby.ext.posix.JavaLibCHelper.readlink(JavaLibCHelper.java:196) at org.jruby.ext.posix.JavaPOSIX.readlink(JavaPOSIX.java:160) at hudson.Util.resolveSymlink(Util.java:1067) at hudson.Util.resolveSymlink(Util.java:1030) at hudson.util.DirScanner$Glob.scan(DirScanner.java:107) at hudson.FilePath.writeToTar(FilePath.java:1781) at hudson.FilePath.access$1000(FilePath.java:166) at hudson.FilePath$36.invoke(FilePath.java:1722) at hudson.FilePath$36.invoke(FilePath.java:1719) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) at java.util.concurrent.FutureTask.run(FutureTask.java:149) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919) at java.lang.Thread.run(Thread.java:736) Build step 'Publish HTML reports' changed build result to FAILURE Recording test results Notifying upstream projects of job completion Finished: FAILURE > Artifact archiving from remote slave fails > -- > > Key: JENKINS-13241 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13241 > Project: Jenkins > Issue Type: Bug > Components: core >Reporter: Vyacheslav Karpukhin > > Since 1.456 jenkins stopped archiving artifacts from remote slave. This > affects both 1.456 and 1.457, works correctly with 1.455. > ERROR: Failed to archive artifacts: build/Release/*.app/**/* > hudson.util.IOException2: hudson.util.IOException2: Failed to extract > /var/jenkins/workspace/NGB_Queues/build/Release/*.app/**/* > at hudson.FilePath.readFromTar(FilePath.java:1817) > at hudson.FilePath.copyRecursiveTo(FilePath.java:1729) > at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) > at > hudson.model.Abst
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162534#comment-162534 ] John Salvo commented on JENKINS-11381: -- Out of curiosity, those experiencing long delays during any SVN operation when they upgraded their SVN plugin to use 1.7/1.8 format .. did you upgrade your working copy from 1.6 to 1.7/1.8 format first ? http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng To quote: "Upgrading the Working Copy Subversion 1.7 introduces substantial changes to the working copy format. In previous releases of Subversion, Subversion would automatically update the working copy to the new format when a write operation was performed. Subversion 1.7, however, will make this a manual step. Before using Subversion 1.7 with their working copies, users will be required to run a new command, svn upgrade to update the metadata to the new format. This command may take a while, and for some users, it may be more practical to simply checkout a new working copy." > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162534#comment-162534 ] John Salvo edited comment on JENKINS-11381 at 5/8/12 11:21 AM: --- Out of curiosity, those experiencing long delays during any SVN operation when they upgraded their SVN plugin to use 1.7 format .. did you upgrade your working copy from 1.6 to 1.7 format first ? http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng To quote: "Upgrading the Working Copy Subversion 1.7 introduces substantial changes to the working copy format. In previous releases of Subversion, Subversion would automatically update the working copy to the new format when a write operation was performed. Subversion 1.7, however, will make this a manual step. Before using Subversion 1.7 with their working copies, users will be required to run a new command, svn upgrade to update the metadata to the new format. This command may take a while, and for some users, it may be more practical to simply checkout a new working copy." was (Author: salvojo): Out of curiosity, those experiencing long delays during any SVN operation when they upgraded their SVN plugin to use 1.7/1.8 format .. did you upgrade your working copy from 1.6 to 1.7/1.8 format first ? http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng To quote: "Upgrading the Working Copy Subversion 1.7 introduces substantial changes to the working copy format. In previous releases of Subversion, Subversion would automatically update the working copy to the new format when a write operation was performed. Subversion 1.7, however, will make this a manual step. Before using Subversion 1.7 with their working copies, users will be required to run a new command, svn upgrade to update the metadata to the new format. This command may take a while, and for some users, it may be more practical to simply checkout a new working copy." > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162535#comment-162535 ] Peter Lillevold commented on JENKINS-11381: --- The question is: will the new SVNKit do an automatic working copy upgrade? Or are we better of scrapping all our existing working copies? > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162536#comment-162536 ] Jan Klass commented on JENKINS-11381: - An automatic upgrade should definitely not be the way to go, as workspaces, tool- and build-chains may depend on the old working copy structure. Maybe a flag setting for enabling an automatic upgrade when the old format is identified would be an option. > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13698) Error 500 on static assets with 1.463-1.1 rpm
[
https://issues.jenkins-ci.org/browse/JENKINS-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162537#comment-162537
]
Mark Doliner commented on JENKINS-13698:
Unfortunately I'm about to be traveling for a few weeks, so I'm unable to test
this. I'll see if someone else at my company will be able to. (I don't see a
newer version of the rpm in the repo, though.)
> Error 500 on static assets with 1.463-1.1 rpm
> -
>
> Key: JENKINS-13698
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13698
> Project: Jenkins
> Issue Type: Bug
> Components: greenballs
>Reporter: Mark Doliner
>Assignee: asgeirn
>
> I yum updated to the jenkins-1.463-1.1 rpm from
> http://pkg.jenkins-ci.org/redhat/ repository today at noon PDT. I'm running
> on CentOS 5.8 with java 1.6.0.
> Since then, logged out users get the following error response for various
> static files (https://server:8443/static/5d0888f6/images/title.png, for
> example):
> {noformat}
> May 7, 2012 1:39:38 PM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.NullPointerException
> at
> hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:50)
> at
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
> at
> hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
> at
> hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at
> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
> at
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
> at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> a
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162538#comment-162538 ] brenuart commented on JENKINS-11381: Don't see any benefit of having such an "auto upgrade" feature... What's the problem in just dropping the workspaces and let Jenkins checkout the projects again ? It's just a one-time operation... > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13698) Error 500 on static assets with 1.463-1.1 rpm
[
https://issues.jenkins-ci.org/browse/JENKINS-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162539#comment-162539
]
Markus Wagner commented on JENKINS-13698:
-
The Green Balls plugin version 1.12 fixed this issue for us.
> Error 500 on static assets with 1.463-1.1 rpm
> -
>
> Key: JENKINS-13698
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13698
> Project: Jenkins
> Issue Type: Bug
> Components: greenballs
>Reporter: Mark Doliner
>Assignee: asgeirn
>
> I yum updated to the jenkins-1.463-1.1 rpm from
> http://pkg.jenkins-ci.org/redhat/ repository today at noon PDT. I'm running
> on CentOS 5.8 with java 1.6.0.
> Since then, logged out users get the following error response for various
> static files (https://server:8443/static/5d0888f6/images/title.png, for
> example):
> {noformat}
> May 7, 2012 1:39:38 PM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.NullPointerException
> at
> hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:50)
> at
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
> at
> hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
> at
> hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> at
> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at
> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
> at
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
> at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {noforma
[JIRA] (JENKINS-13154) Heavy thread congestion with FingerPrint.save
[ https://issues.jenkins-ci.org/browse/JENKINS-13154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikko Peltonen reopened JENKINS-13154: -- Jenkins 1.463 did not fix this problem for us. We're still seeing similar congestion, and many of our builds are stuck for tens of minutes in "Waiting for Jenkins to finish collecting data" at the end of the build. I'll attach another thread dump taken with 1.463. > Heavy thread congestion with FingerPrint.save > - > > Key: JENKINS-13154 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13154 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: System Properties > Name ↓ Value > awt.toolkit sun.awt.X11.XToolkit > executable-war/foobar/jenkins/jenkins.war > file.encoding UTF-8 > file.encoding.pkg sun.io > file.separator/ > guice.disable.misplaced.annotation.check true > hudson.diyChunkingtrue > hudson.upstreamCulprits true > java.awt.graphicsenv sun.awt.X11GraphicsEnvironment > java.awt.headless true > java.awt.printerjob sun.print.PSPrinterJob > java.class.path /foobar/jenkins/jenkins.war > java.class.version51.0 > java.endorsed.dirs/foobar/dist/jdk/jdk1.7.0_02/jre/lib/endorsed > java.ext.dirs > /foobar/dist/jdk/jdk1.7.0_02/jre/lib/ext:/usr/java/packages/lib/ext > java.home /foobar/dist/jdk/jdk1.7.0_02/jre > java.io.tmpdir/foobar/scratch > java.library.path > /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib > java.runtime.name Java(TM) SE Runtime Environment > java.runtime.version 1.7.0_02-b13 > java.specification.name Java Platform API Specification > java.specification.vendor Oracle Corporation > java.specification.version1.7 > java.vendor Oracle Corporationa > java.vendor.url http://java.oracle.com/ > java.vendor.url.bug http://bugreport.sun.com/bugreport/ > java.version 1.7.0_02 > java.vm.info mixed mode > java.vm.name Java HotSpot(TM) 64-Bit Server VM > java.vm.specification.nameJava Virtual Machine Specification > java.vm.specification.vendor Oracle Corporation > java.vm.specification.version 1.7 > java.vm.vendorOracle Corporation > java.vm.version 22.0-b10 > jna.platform.library.path /usr/lib64:/lib64:/usr/lib:/lib > line.separator > mail.smtp.sendpartial true > mail.smtps.sendpartialtrue > os.arch amd64 > os.name Linux > os.version2.6.18-164.15.1.el5 > path.separator: > securerandom.source file:/dev/./urandom > sun.arch.data.model 64 > sun.boot.class.path > /foobar/dist/jdk/jdk1.7.0_02/jre/lib/resources.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/rt.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/sunrsasign.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/jsse.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/jce.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/charsets.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/classes > sun.boot.library.path /foobar/dist/jdk/jdk1.7.0_02/jre/lib/amd64 > sun.cpu.endianlittle > sun.cpu.isalist > sun.io.unicode.encoding UnicodeLittle > sun.java.command /foobar/jenkins/jenkins.war --httpPort=8088 > sun.java.launcher SUN_STANDARD > sun.jnu.encoding UTF-8 > sun.management.compiler HotSpot 64-Bit Tiered Compilers > sun.os.patch.levelunknown > svnkit.http.methods Digest,Basic,NTLM,Negotiate > svnkit.ssh2.persistentfalse > user.country FI > user.dir /foobar/jenkins > user.home /foobar/baz > user.language fi > user.name baz > user.timezone Europe/Helsinki > Environment Variables > Name ↓ Value > G_BROKEN_FILENAMES1 > HISTSIZE 1000 > HOME /foobar/baz > HUDSON_HOME /foobar/jenkins > INPUTRC /etc/inputrc > JAVA_HOME /foobar/dist/jdk/current > JENKINS_HOME /foobar/jenkins > JETTYENV_HOME /foobar/baz/env-jetty > LANG en_US.UTF-8 > LC_ADDRESSfi_FI.UTF-8 > LC_ALLfi_FI.utf8 > LC_CTYPE fi_FI.UTF-8 > LC_IDENTIFICATION fi_FI.UTF-8 > LC_MEASUREMENTfi_FI.UTF-8 > LC_MONETARY fi_FI.UTF-8 > LC_NAME fi_FI.UTF-8 > LC_PAPER fi_FI.UTF-8 > LC_TELEPHONE fi_FI.UTF-8 > LESSOPEN |/usr/bin/lesspipe.sh %s > LOGNAME baz > LS_COLORS > M2_HOME /foobar/dist/maven/current > MAIL /var/spool/mail/baz > MAVEN_OPTS-XX:+UseCompressedOops -Djava.security.egd=file:///dev/urandom > -Xmx512m > MVN /foobar/dist/maven/current/bin/mvn > NLSPATH /usr/dt/lib/nls/msg/%L/%N.cat > PAGER less > PATH > /opt/CollabNet_Subversion/bin:/opt/CollabNet_Subversion/bin:/foobar/dist/jdk/current/bin:/foobar/dist/maven/current/bin:/foobar/baz/env-jetty/bin:/foobar/baz/env-jetty/dist/jdk/current/bin:/foobar/baz/env-fab/bin:/foobar/baz/env-apache/bin:/foobar/baz/bin:/foobar/baz/python/bin:/foobar/dist/jdk/current
[JIRA] (JENKINS-13154) Heavy thread congestion with FingerPrint.save
[ https://issues.jenkins-ci.org/browse/JENKINS-13154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikko Peltonen updated JENKINS-13154: - Attachment: threads_sample_jenkins_1.463.txt Thread dump taken with Jenkins 1.463, showing the problem still exists. > Heavy thread congestion with FingerPrint.save > - > > Key: JENKINS-13154 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13154 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: System Properties > Name ↓ Value > awt.toolkit sun.awt.X11.XToolkit > executable-war/foobar/jenkins/jenkins.war > file.encoding UTF-8 > file.encoding.pkg sun.io > file.separator/ > guice.disable.misplaced.annotation.check true > hudson.diyChunkingtrue > hudson.upstreamCulprits true > java.awt.graphicsenv sun.awt.X11GraphicsEnvironment > java.awt.headless true > java.awt.printerjob sun.print.PSPrinterJob > java.class.path /foobar/jenkins/jenkins.war > java.class.version51.0 > java.endorsed.dirs/foobar/dist/jdk/jdk1.7.0_02/jre/lib/endorsed > java.ext.dirs > /foobar/dist/jdk/jdk1.7.0_02/jre/lib/ext:/usr/java/packages/lib/ext > java.home /foobar/dist/jdk/jdk1.7.0_02/jre > java.io.tmpdir/foobar/scratch > java.library.path > /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib > java.runtime.name Java(TM) SE Runtime Environment > java.runtime.version 1.7.0_02-b13 > java.specification.name Java Platform API Specification > java.specification.vendor Oracle Corporation > java.specification.version1.7 > java.vendor Oracle Corporationa > java.vendor.url http://java.oracle.com/ > java.vendor.url.bug http://bugreport.sun.com/bugreport/ > java.version 1.7.0_02 > java.vm.info mixed mode > java.vm.name Java HotSpot(TM) 64-Bit Server VM > java.vm.specification.nameJava Virtual Machine Specification > java.vm.specification.vendor Oracle Corporation > java.vm.specification.version 1.7 > java.vm.vendorOracle Corporation > java.vm.version 22.0-b10 > jna.platform.library.path /usr/lib64:/lib64:/usr/lib:/lib > line.separator > mail.smtp.sendpartial true > mail.smtps.sendpartialtrue > os.arch amd64 > os.name Linux > os.version2.6.18-164.15.1.el5 > path.separator: > securerandom.source file:/dev/./urandom > sun.arch.data.model 64 > sun.boot.class.path > /foobar/dist/jdk/jdk1.7.0_02/jre/lib/resources.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/rt.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/sunrsasign.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/jsse.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/jce.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/lib/charsets.jar:/foobar/dist/jdk/jdk1.7.0_02/jre/classes > sun.boot.library.path /foobar/dist/jdk/jdk1.7.0_02/jre/lib/amd64 > sun.cpu.endianlittle > sun.cpu.isalist > sun.io.unicode.encoding UnicodeLittle > sun.java.command /foobar/jenkins/jenkins.war --httpPort=8088 > sun.java.launcher SUN_STANDARD > sun.jnu.encoding UTF-8 > sun.management.compiler HotSpot 64-Bit Tiered Compilers > sun.os.patch.levelunknown > svnkit.http.methods Digest,Basic,NTLM,Negotiate > svnkit.ssh2.persistentfalse > user.country FI > user.dir /foobar/jenkins > user.home /foobar/baz > user.language fi > user.name baz > user.timezone Europe/Helsinki > Environment Variables > Name ↓ Value > G_BROKEN_FILENAMES1 > HISTSIZE 1000 > HOME /foobar/baz > HUDSON_HOME /foobar/jenkins > INPUTRC /etc/inputrc > JAVA_HOME /foobar/dist/jdk/current > JENKINS_HOME /foobar/jenkins > JETTYENV_HOME /foobar/baz/env-jetty > LANG en_US.UTF-8 > LC_ADDRESSfi_FI.UTF-8 > LC_ALLfi_FI.utf8 > LC_CTYPE fi_FI.UTF-8 > LC_IDENTIFICATION fi_FI.UTF-8 > LC_MEASUREMENTfi_FI.UTF-8 > LC_MONETARY fi_FI.UTF-8 > LC_NAME fi_FI.UTF-8 > LC_PAPER fi_FI.UTF-8 > LC_TELEPHONE fi_FI.UTF-8 > LESSOPEN |/usr/bin/lesspipe.sh %s > LOGNAME baz > LS_COLORS > M2_HOME /foobar/dist/maven/current > MAIL /var/spool/mail/baz > MAVEN_OPTS-XX:+UseCompressedOops -Djava.security.egd=file:///dev/urandom > -Xmx512m > MVN /foobar/dist/maven/current/bin/mvn > NLSPATH /usr/dt/lib/nls/msg/%L/%N.cat > PAGER less > PATH > /opt/CollabNet_Subversion/bin:/opt/CollabNet_Subversion/bin:/foobar/dist/jdk/current/bin:/foobar/dist/maven/current/bin:/foobar/baz/env-jetty/bin:/foobar/baz/env-jetty/dist/jdk/current/bin:/foobar/baz/env-fab/bin:/foobar/baz/env-apache/bin:/foobar/baz/bin:/foobar/baz/python/bin:/foobar/dist/jdk/current/bin:/foobar/dist/maven/current/bin:/opt/CollabNet_Subversion/bin/:/foobar/scala-2.9.1.final/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162542#comment-162542 ] Dan Lewis commented on JENKINS-11381: - agree. bonus points if we can fail fast with an appropriate error message explaining corrective procedure, e.g. "jenkins does not support auto-update of pre-SVN 1.7 workspaces to 1.7; please remove workspaces and restart build" or some such > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13708) Check for Modifications feature does not check sub-projects (erroneously does not build after check-ins detected)
Michael Lumsden created JENKINS-13708: - Summary: Check for Modifications feature does not check sub-projects (erroneously does not build after check-ins detected) Key: JENKINS-13708 URL: https://issues.jenkins-ci.org/browse/JENKINS-13708 Project: Jenkins Issue Type: Bug Components: synergy Affects Versions: current Environment: Jenkins 1.462, Synergy Plugin v1.6, Synergy v6.5, Linux OS Reporter: Michael Lumsden Assignee: jribette Priority: Critical Our SCM system is setup such that a number of projects in Synergy all inherit from (are child projects of) one "Master" project. To perform such builds in Jenkins, the project we are referencing is a build-user copy of the Master project (in a working state). If someone checked in files that affect/are related to sub-projects off that Master project in Synergy, then the SCM Polling within Jenkins Synergy plugin successfully identifies that changes occurred, but the "Check for Modifications" feature prevents the build from being triggered. This appears to be because the changes did NOT directly affect members/sub-directories of the Master project, but instead of sub-projects within Master. This would seem to be a bug, since the perceived intent of the "Check for Modifications" feature is to prevent check-ins that are to the same Synergy Release Attribute but to unrelated Synergy SCM projects from kicking off Jenkins builds of unrelated projects, but a sub-project off a "Master" is indeed related and should thus trigger a build if changes are detected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13703) AJP support does not respect the specs. breaks with SSL
[ https://issues.jenkins-ci.org/browse/JENKINS-13703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jeanson updated JENKINS-13703: -- Labels: winstone (was: ) > AJP support does not respect the specs. breaks with SSL > --- > > Key: JENKINS-13703 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13703 > Project: Jenkins > Issue Type: Bug > Components: www >Affects Versions: current >Reporter: Simon Poirier > Labels: winstone > Attachments: ajp_ssl.patch > > > According to this bug > https://issues.apache.org/bugzilla/show_bug.cgi?id=39658 an the mod_jk > documentation, ssl_key_size attribute is passed as an integer. > Winstone parses it as a string and generates a stack trace. > Steps to reproduce: > 1. Start jenkins in standalone mode with AJP activated on some port > 2. Setup a reverse proxy on apache on a virtualhost which has ssl configured > 3. navigate to https://rproxy.address/jenkins > Results > - Apache returns an "Internal error" > - /var/log/jenkins/jenkins.log is filled with EOFException stack such as this > one > java.io.EOFException > at java.io.DataInputStream.readFully(DataInputStream.java:197) > at java.io.DataInputStream.readFully(DataInputStream.java:169) > at > winstone.ajp13.Ajp13IncomingPacket.readString(Ajp13IncomingPacket.java:244) > at > winstone.ajp13.Ajp13IncomingPacket.readString(Ajp13IncomingPacket.java:231) > at > winstone.ajp13.Ajp13IncomingPacket.parsePacket(Ajp13IncomingPacket.java:168) > at > winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:184) > at winstone.RequestHandlerThread.run(RequestHandlerThread.java:67) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) > Expected behaviour: > A jenkins page, like when using http -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162543#comment-162543 ] Jan Klass commented on JENKINS-11381: - I installed version 140RC locally. The parametrized build (List subversion tags and more) only lists trunk. See also the other ticket https://issues.jenkins-ci.org/browse/JENKINS-11933?focusedCommentId=162399#comment-162399 On Configuration: The repository is being accepted as valid, root path as well as subpaths. Did not check out on it yet. > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[
https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162544#comment-162544
]
Jan Klass commented on JENKINS-11381:
-
I just tried to check out a fresh copy, which did not succeed.
The URI was a subpath of trunk, so not trunk itself.
{quote}
Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder
doesn't exist
Cleaning local Directory MyFolder
Checking out svn://srv/repopath/trunk/MyFolder
ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
org.tmatesoft.svn.core.SVNException: svn: E155007:
'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy
{quote}
> Subversion Plugin does not support Subversion 1.7
> -
>
> Key: JENKINS-11381
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11381
> Project: Jenkins
> Issue Type: Improvement
> Components: subversion
>Reporter: soundworker
>Priority: Blocker
> Attachments: subversion.hpi
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[
https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162544#comment-162544
]
Jan Klass edited comment on JENKINS-11381 at 5/8/12 3:12 PM:
-
I just tried to check out a fresh copy, which did not succeed.
The URI was a subpath of trunk, so not trunk itself.
{quote}
Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder
doesn't exist
Cleaning local Directory MyFolder
Checking out svn://srv/repopath/trunk/MyFolder
ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
org.tmatesoft.svn.core.SVNException: svn: E155007:
'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy
{quote}
Checking out to a 1.6 workspace instead of 1.7 worked with the same settings.
was (Author: jk):
I just tried to check out a fresh copy, which did not succeed.
The URI was a subpath of trunk, so not trunk itself.
{quote}
Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder
doesn't exist
Cleaning local Directory MyFolder
Checking out svn://srv/repopath/trunk/MyFolder
ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
org.tmatesoft.svn.core.SVNException: svn: E155007:
'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy
{quote}
> Subversion Plugin does not support Subversion 1.7
> -
>
> Key: JENKINS-11381
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11381
> Project: Jenkins
> Issue Type: Improvement
> Components: subversion
>Reporter: soundworker
>Priority: Blocker
> Attachments: subversion.hpi
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[
https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162544#comment-162544
]
Jan Klass edited comment on JENKINS-11381 at 5/8/12 3:12 PM:
-
I just tried to check out a fresh copy, which did not succeed.
The URI was a subpath of trunk, so not trunk itself.
{quote}
Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder
doesn't exist
Cleaning local Directory MyFolder
Checking out svn://srv/repopath/trunk/MyFolder
ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
org.tmatesoft.svn.core.SVNException: svn: E155007:
'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy
{quote}
Checking out to a 1.6 workspace instead of 1.7 worked with the same
configuration.
was (Author: jk):
I just tried to check out a fresh copy, which did not succeed.
The URI was a subpath of trunk, so not trunk itself.
{quote}
Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder
doesn't exist
Cleaning local Directory MyFolder
Checking out svn://srv/repopath/trunk/MyFolder
ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
org.tmatesoft.svn.core.SVNException: svn: E155007:
'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy
{quote}
Checking out to a 1.6 workspace instead of 1.7 worked with the same settings.
> Subversion Plugin does not support Subversion 1.7
> -
>
> Key: JENKINS-11381
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11381
> Project: Jenkins
> Issue Type: Improvement
> Components: subversion
>Reporter: soundworker
>Priority: Blocker
> Attachments: subversion.hpi
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[
https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162544#comment-162544
]
Jan Klass edited comment on JENKINS-11381 at 5/8/12 3:14 PM:
-
I just tried to check out a fresh copy, which did not succeed.
The URI was a subpath of trunk, so not trunk itself.
{quote}
Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder
doesn't exist
Cleaning local Directory MyFolder
Checking out svn://srv/repopath/trunk/MyFolder
ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
org.tmatesoft.svn.core.SVNException: svn: E155007:
'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy
{quote}
Checking out to a 1.6 workspace instead of 1.7 worked with the same
configuration.
/e:
Checking out trunk to a 1.7 workspace fails as well, same error.
was (Author: jk):
I just tried to check out a fresh copy, which did not succeed.
The URI was a subpath of trunk, so not trunk itself.
{quote}
Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder
doesn't exist
Cleaning local Directory MyFolder
Checking out svn://srv/repopath/trunk/MyFolder
ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
org.tmatesoft.svn.core.SVNException: svn: E155007:
'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy
{quote}
Checking out to a 1.6 workspace instead of 1.7 worked with the same
configuration.
> Subversion Plugin does not support Subversion 1.7
> -
>
> Key: JENKINS-11381
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11381
> Project: Jenkins
> Issue Type: Improvement
> Components: subversion
>Reporter: soundworker
>Priority: Blocker
> Attachments: subversion.hpi
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162545#comment-162545 ] Amir Isfy commented on JENKINS-13227: - Thanks Michael. > CVS plugin 2.1 does not detect changes > -- > > Key: JENKINS-13227 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13227 > Project: Jenkins > Issue Type: Bug > Components: cvs >Reporter: Guillaume Bilodeau >Assignee: Michael Clarke >Priority: Critical > Labels: cvs > Attachments: rlog.txt > > > As presented in the user group: > https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4 > We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS > repository for a few weeks now, without any problems. The CVS plugin (v1.6) > was using the local cvsnt install. > We've since upgraded the CVS plugin to version 2.1 (by manually pinning the > plugin) and since then, CVS changes are not detected. The CVS polling log is > triggered properly, tons of "cvs rlog" instructions are sent, but at the end > "No changes" is displayed. > Using CVS plugin 1.6 the cvs polling command looked like this (executed at > 5:26:21 PM EDT): > cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D > "Thursday, March 22, 2012 9:26:21 PM UTC" > Using CVS plugin 2.1, the last cvs checkout command looked like this > (executed at 11:56:16 AM EDT): > cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 > 11:56:16 EDT -d portailInt portailInt > We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13709) ClassCast Exception when parsing JUnit surefire reports during website generation
scooper4711 created JENKINS-13709: - Summary: ClassCast Exception when parsing JUnit surefire reports during website generation Key: JENKINS-13709 URL: https://issues.jenkins-ci.org/browse/JENKINS-13709 Project: Jenkins Issue Type: Bug Components: junit Affects Versions: current Environment: Linux 64-bit, jenkins 1.462, java 7, maven 3.0.4 Reporter: scooper4711 When generating a website with mvn clean site site:deploy, I will consistently get a ClassCastException when jenkins is trying to parse the junit surefire reports. This does not happen if I run the command from the command-line, and interestingly enough it doesn't happen for the non-site build (e.g. mvn clean deploy) --- T E S T S --- Running com.ften.creditpool.latency.ThroughputStatsTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.566 sec Running com.ften.creditpool.latency.ThroughputCreditPoolTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running com.ften.creditpool.latency.MinMaxAverageTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running com.ften.creditpool.audit.AuditingCreditPoolTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Running com.ften.creditpool.CreditPoolBeanTest Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Results : Tests run: 29, Failures: 0, Errors: 0, Skipped: 0 mojoSucceeded org.apache.maven.plugins:maven-surefire-plugin:2.12(default-test) [JENKINS] Recording test results hudson.util.IOException2: Failed to read /var/lib/jenkins/jobs/risk-alerts_site/workspace/credit-pool/target/surefire-reports/TEST-com.ften.creditpool.CreditPoolBeanTest.xml at hudson.tasks.junit.TestResult.parse(TestResult.java:244) at hudson.tasks.junit.TestResult.parse(TestResult.java:163) at hudson.maven.reporters.SurefireArchiver.postExecute(SurefireArchiver.java:141) at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:421) at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:403) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:87) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:228) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:173) at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildReportPlugin(DefaultMavenReportExecutor.java:284) at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:150) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:247) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classwo
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162546#comment-162546 ] Kohsuke Kawaguchi commented on JENKINS-11381: - There has been and is a global configuration where you choose the working copy format version. So if the auto-upgrade is possible with SVNKit, I don't see any harm in doing so when this global configuration points to 1.7. The main problem right now for me is that I don't know how to make it happen. Jan, what is the Subversion server version? You said you saw that error while you were checking out to 1.7 workspace format? Also, please don't truncate the stack trace, because it is invaluable for me to understand where things failed. > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[
https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162547#comment-162547
]
Jan Klass commented on JENKINS-11381:
-
On the questions Kohsuke asked:
> When this error happens, do you have C:\Data\Jenkins\workspace\job\src\.svn?
> I step executed the code and it does create the workspace right before the
> code gets to here.
No. Neither the .svn folder nor the folder it should be placed in is being
created.
Even if I create the target folder myself, no .svn folder is being created.
> The other experiment I'd like you to try is to use the scripting console, run
> "org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.ourFactories;",
> and report back what you see. I wonder if someone else is setting that
> collection to empty, which would explain this.
{quote}
Result:
[org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory@1b4d6c0,
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea15Factory@17f0649,
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14Factory@75c229,
org.tmatesoft.svn.core.internal.wc.admin.SVNXMLAdminAreaFactory@11e4232]
{quote}
> Subversion Plugin does not support Subversion 1.7
> -
>
> Key: JENKINS-11381
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11381
> Project: Jenkins
> Issue Type: Improvement
> Components: subversion
>Reporter: soundworker
>Priority: Blocker
> Attachments: subversion.hpi
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[
https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162547#comment-162547
]
Jan Klass edited comment on JENKINS-11381 at 5/8/12 3:58 PM:
-
On the questions Kohsuke asked:
{quote}When this error happens, do you have
C:\Data\Jenkins\workspace\job\src\.svn? I step executed the code and it does
create the workspace right before the code gets to here.{quote}
No. Neither the .svn folder nor the folder it should be placed in is being
created.
Even if I create the target folder myself, no .svn folder is being created.
{quote}The other experiment I'd like you to try is to use the scripting
console, run
"org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.ourFactories;",
and report back what you see. I wonder if someone else is setting that
collection to empty, which would explain this.{quote}
{quote}
Result:
[org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory@1b4d6c0,
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea15Factory@17f0649,
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14Factory@75c229,
org.tmatesoft.svn.core.internal.wc.admin.SVNXMLAdminAreaFactory@11e4232]
{quote}
was (Author: jk):
On the questions Kohsuke asked:
> When this error happens, do you have C:\Data\Jenkins\workspace\job\src\.svn?
> I step executed the code and it does create the workspace right before the
> code gets to here.
No. Neither the .svn folder nor the folder it should be placed in is being
created.
Even if I create the target folder myself, no .svn folder is being created.
> The other experiment I'd like you to try is to use the scripting console, run
> "org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.ourFactories;",
> and report back what you see. I wonder if someone else is setting that
> collection to empty, which would explain this.
{quote}
Result:
[org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory@1b4d6c0,
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea15Factory@17f0649,
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14Factory@75c229,
org.tmatesoft.svn.core.internal.wc.admin.SVNXMLAdminAreaFactory@11e4232]
{quote}
> Subversion Plugin does not support Subversion 1.7
> -
>
> Key: JENKINS-11381
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11381
> Project: Jenkins
> Issue Type: Improvement
> Components: subversion
>Reporter: soundworker
>Priority: Blocker
> Attachments: subversion.hpi
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[
https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162544#comment-162544
]
Jan Klass edited comment on JENKINS-11381 at 5/8/12 3:54 PM:
-
I just tried to check out a fresh copy, which did not succeed.
The URI was a subpath of trunk, so not trunk itself.
{quote}
Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder
doesn't exist
Cleaning local Directory MyFolder
Checking out svn://srv/repopath/trunk/MyFolder
ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
org.tmatesoft.svn.core.SVNException: svn: E155007:
'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy
{quote}
Checking out to a 1.6 workspace instead of 1.7 worked with the same
configuration.
/e:
Checking out trunk to a 1.7 workspace fails as well, same error.
/e:
Checking out a 1.7 working copy manually - to the target path - before the
build starts (so, without jenkins),
jenkins does run an update on the working copy, the checked out path.
Going back to an older revision on the 1.7 working copy Jenkins does indeed
update to HEAD.
Just the new checkout to 1.7 workspace seems to fail.
was (Author: jk):
I just tried to check out a fresh copy, which did not succeed.
The URI was a subpath of trunk, so not trunk itself.
{quote}
Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder
doesn't exist
Cleaning local Directory MyFolder
Checking out svn://srv/repopath/trunk/MyFolder
ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
org.tmatesoft.svn.core.SVNException: svn: E155007:
'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy
{quote}
Checking out to a 1.6 workspace instead of 1.7 worked with the same
configuration.
/e:
Checking out trunk to a 1.7 workspace fails as well, same error.
> Subversion Plugin does not support Subversion 1.7
> -
>
> Key: JENKINS-11381
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11381
> Project: Jenkins
> Issue Type: Improvement
> Components: subversion
>Reporter: soundworker
>Priority: Blocker
> Attachments: subversion.hpi
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13710) priority not applied on build triggered job immediately
Greg Moncreaff created JENKINS-13710: Summary: priority not applied on build triggered job immediately Key: JENKINS-13710 URL: https://issues.jenkins-ci.org/browse/JENKINS-13710 Project: Jenkins Issue Type: Bug Components: prioritysorter Reporter: Greg Moncreaff Assignee: bklarson I have jobs/priorities A (200), B (300), C (400) A and B are using SCM trigger but diffing scope/time (A is a superset of B). C is a downstream job of B that needs products that B leaves behind in the workspace. A cleans all workspace (clearcase private) files. problem is that even though C is higher priority than A, if A is next in the build Q, the priority application is too late and A starts before C so that when C gets a chance to run, it fails as its needed inputs from the workspace no longer exist. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10771) hudson.util.IOException2: remote file operation failed
[ https://issues.jenkins-ci.org/browse/JENKINS-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162548#comment-162548 ] linfa zhu commented on JENKINS-10771: - ===I have similar issue which could be resolved by reconnect to the slave, but it is painful since 5 out of 20 slave have this issue. The slave of the problems are all on other state, so it maybe due to slow response ( I am just guessing ). it happens on linux, aix, hp-ux slaves FATAL: command execution failed java.io.IOException: Remote call on hp88 failed at hudson.remoting.Channel.call(Channel.java:690) at hudson.Launcher$RemoteLauncher.launch(Launcher.java:796) at hudson.Launcher$ProcStarter.start(Launcher.java:338) at hudson.Launcher$ProcStarter.join(Launcher.java:345) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:82) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at hudson.model.Build$RunnerImpl.build(Build.java:178) at hudson.model.Build$RunnerImpl.doRun(Build.java:139) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1409) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) ===Also, if I use copy-to-slave plugin, it shows another crash, but I think they are from the same root cause FATAL: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command hudson.util.IOException2: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command at com.michelin.cio.hudson.plugins.copytoslave.MyFilePath.copyRecursiveTo(MyFilePath.java:147) at com.michelin.cio.hudson.plugins.copytoslave.CopyToSlaveBuildWrapper.setUp(CopyToSlaveBuildWrapper.java:133) at hudson.model.Build$RunnerImpl.doRun(Build.java:133) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1409) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) > hudson.util.IOException2: remote file operation failed > -- > > Key: JENKINS-10771 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10771 > Project: Jenkins > Issue Type: Bug > Components: master-slave >Affects Versions: current > Environment: node: Windows Server 2008 R2, amd64 - Intel64 Family 6 > Model 15 Stepping 1, GenuineIntel, jvm 1.6.0_25-b06 > master: AIX >Reporter: Thorsten Löber > > After upgrading jenkins from 1.415 to 1.426 we cannot build anymore any > project on our windows node. We get the exception: > Building remotely on WSJENKINSDEV01 > hudson.util.IOException2: remote file operation failed: d:\Program > Files\jenkins_slave\workspace\TASC Workbench at > hudson.remoting.Channel@4f854f85:WSJENKINSDEV01 > at hudson.FilePath.act(FilePath.java:754) > at hudson.FilePath.act(FilePath.java:740) > at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:731) > at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:676) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1193) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:555) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:443) > at hudson.model.Run.run(Run.java:1376) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:230) > Caused by: java.io.IOException: Remote call on WSJENKINSDEV01 failed > at hudson.remoting.Channel.call(Channel.java:677) > at hudson.FilePath.act(FilePath.java:747) > ... 10 more > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > hudson.model.Hudson > at > hudson.scm.SubversionWorkspaceSelector.syncWorkspaceFormatFromMaster(SubversionWorkspaceSelector.java:85) > at > hudson.scm.SubversionSCM.createSvnClientManager(SubversionSCM.java:808) > at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:751) > at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:738) > at hudson.FilePath$FileCallableWrapper.call(
[JIRA] (JENKINS-10771) hudson.util.IOException2: remote file operation failed
[ https://issues.jenkins-ci.org/browse/JENKINS-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162548#comment-162548 ] linfa zhu edited comment on JENKINS-10771 at 5/8/12 4:02 PM: - ===I have similar issue which could be resolved by reconnect to the slave, but it is painful since 5 out of 20 slave have this issue after restarting jenkins server everytime. The slave having problems are all on other state, so it maybe due to slow response ( I am just guessing ). it happens on linux, aix, hp-ux slaves FATAL: command execution failed java.io.IOException: Remote call on hp88 failed at hudson.remoting.Channel.call(Channel.java:690) at hudson.Launcher$RemoteLauncher.launch(Launcher.java:796) at hudson.Launcher$ProcStarter.start(Launcher.java:338) at hudson.Launcher$ProcStarter.join(Launcher.java:345) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:82) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at hudson.model.Build$RunnerImpl.build(Build.java:178) at hudson.model.Build$RunnerImpl.doRun(Build.java:139) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1409) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) ===Also, if I use copy-to-slave plugin, it shows another crash, but I think they are from the same root cause FATAL: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command hudson.util.IOException2: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command at com.michelin.cio.hudson.plugins.copytoslave.MyFilePath.copyRecursiveTo(MyFilePath.java:147) at com.michelin.cio.hudson.plugins.copytoslave.CopyToSlaveBuildWrapper.setUp(CopyToSlaveBuildWrapper.java:133) at hudson.model.Build$RunnerImpl.doRun(Build.java:133) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1409) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) was (Author: linfa): ===I have similar issue which could be resolved by reconnect to the slave, but it is painful since 5 out of 20 slave have this issue. The slave of the problems are all on other state, so it maybe due to slow response ( I am just guessing ). it happens on linux, aix, hp-ux slaves FATAL: command execution failed java.io.IOException: Remote call on hp88 failed at hudson.remoting.Channel.call(Channel.java:690) at hudson.Launcher$RemoteLauncher.launch(Launcher.java:796) at hudson.Launcher$ProcStarter.start(Launcher.java:338) at hudson.Launcher$ProcStarter.join(Launcher.java:345) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:82) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at hudson.model.Build$RunnerImpl.build(Build.java:178) at hudson.model.Build$RunnerImpl.doRun(Build.java:139) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1409) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) ===Also, if I use copy-to-slave plugin, it shows another crash, but I think they are from the same root cause FATAL: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command hudson.util.IOException2: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command at com.michelin.cio.hudson.plugins.copytoslave.MyFilePath.copyRecursiveTo(MyFilePath.java:147) at com.michelin.cio.hudson.plugins.copytoslave.CopyToSlaveBuildWrapper.setUp(CopyToSlaveBuildWrapper.java:133) at hudson.model.Build$RunnerImpl.doRun(Build.java:133) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.jav
[JIRA] (JENKINS-13398) support for starteam cache agents
[ https://issues.jenkins-ci.org/browse/JENKINS-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162549#comment-162549 ] mistafunk commented on JENKINS-13398: - i have made some modifications to enable a starteam cache. it's quick and dirty but it seems to work fine (used it for 4 weeks in production): https://github.com/mistafunk/starteam-plugin/commit/58249bf78db0fc25e36ea8141b2571072bc19f0e > support for starteam cache agents > - > > Key: JENKINS-13398 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13398 > Project: Jenkins > Issue Type: Improvement > Components: starteam >Affects Versions: current >Reporter: mistafunk >Assignee: jan_ruzicka >Priority: Minor > > it would be nice to have support for starteam cache agents, this would > accelerate checkouts quite a bit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10771) hudson.util.IOException2: remote file operation failed
[ https://issues.jenkins-ci.org/browse/JENKINS-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162548#comment-162548 ] linfa zhu edited comment on JENKINS-10771 at 5/8/12 4:03 PM: - ===I have similar issue which could be resolved by reconnect to the slave, but it is painful since 5 out of 20 slave have this issue after restarting jenkins server everytime. The slave having problems are all on other state, so it maybe due to slow response ( I am just guessing ). it happens on linux, aix, hp-ux slaves. jenkins version is 1.451 FATAL: command execution failed java.io.IOException: Remote call on hp88 failed at hudson.remoting.Channel.call(Channel.java:690) at hudson.Launcher$RemoteLauncher.launch(Launcher.java:796) at hudson.Launcher$ProcStarter.start(Launcher.java:338) at hudson.Launcher$ProcStarter.join(Launcher.java:345) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:82) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at hudson.model.Build$RunnerImpl.build(Build.java:178) at hudson.model.Build$RunnerImpl.doRun(Build.java:139) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1409) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) ===Also, if I use copy-to-slave plugin, it shows another crash, but I think they are from the same root cause FATAL: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command hudson.util.IOException2: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command at com.michelin.cio.hudson.plugins.copytoslave.MyFilePath.copyRecursiveTo(MyFilePath.java:147) at com.michelin.cio.hudson.plugins.copytoslave.CopyToSlaveBuildWrapper.setUp(CopyToSlaveBuildWrapper.java:133) at hudson.model.Build$RunnerImpl.doRun(Build.java:133) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1409) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) was (Author: linfa): ===I have similar issue which could be resolved by reconnect to the slave, but it is painful since 5 out of 20 slave have this issue after restarting jenkins server everytime. The slave having problems are all on other state, so it maybe due to slow response ( I am just guessing ). it happens on linux, aix, hp-ux slaves FATAL: command execution failed java.io.IOException: Remote call on hp88 failed at hudson.remoting.Channel.call(Channel.java:690) at hudson.Launcher$RemoteLauncher.launch(Launcher.java:796) at hudson.Launcher$ProcStarter.start(Launcher.java:338) at hudson.Launcher$ProcStarter.join(Launcher.java:345) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:82) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at hudson.model.Build$RunnerImpl.build(Build.java:178) at hudson.model.Build$RunnerImpl.doRun(Build.java:139) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1409) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) ===Also, if I use copy-to-slave plugin, it shows another crash, but I think they are from the same root cause FATAL: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command hudson.util.IOException2: java.lang.IllegalAccessError: class hudson.remoting.Pipe$ConnectCommand cannot access its superclass hudson.remoting.Command at com.michelin.cio.hudson.plugins.copytoslave.MyFilePath.copyRecursiveTo(MyFilePath.java:147) at com.michelin.cio.hudson.plugins.copytoslave.CopyToSlaveBuildWrapper.setUp(CopyToSlaveBuildWrapper.java:133) at hudson.model.Build$RunnerImpl.doRun(Build.java:133) at hudson.model.AbstractBuild$AbstractRunne
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[
https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162550#comment-162550
]
Jan Klass commented on JENKINS-11381:
-
Here is the full stack trace. Path/Folder-names replaced.
MyFolder1 is a 1.7 working copy I checked out manually before-hand.
MyFolder2 is the Path it is supposed to check out as a 1.7 working copy.
{quote}
Gestartet durch Benutzer anonymous
Baue auf Slave local2 in workspace c:\jenkins\workspace\Proj Name
Updating svn://srv/path/ProjRepo/trunk/MyFolder1
At revision 32522
Checking out a fresh workspace because there's no workspace at
C:\jenkins\workspace\Proj Name\MyFolder2
Cleaning local Directory MyFolder2
Checking out svn://srv/path/ProjRepo/trunk/MyFolder2
ERROR: Failed to check out svn://srv/path/ProjRepo/trunk/MyFolder2
org.tmatesoft.svn.core.SVNException: svn: E155007: 'C:\jenkins\workspace\Proj
Name\MyFolder2' is not a working copy
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:170)
at
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:379)
at
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:283)
at
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:276)
at
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.openAnchor(SVNWCAccess.java:171)
at
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:514)
at
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doCheckout(SVNUpdateClient16.java:965)
at
org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:19)
at
org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:8)
at
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
at
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:86)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
at
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:60)
at java.lang.Thread.run(Unknown Source)
Caused by: svn: E155007: 'C:\jenkins\workspace\Proj Name\MyFolder2' is not a
working copy
at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171)
at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126)
at
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:165)
... 31 more
FATAL: null
java.lang.NullPointerException
at java.util.ArrayList.addAll(Unknown Source)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
at
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
{quote}
> Subversion Plugin does not suppo
[JIRA] (JENKINS-12869) Maven Build fails when integration/system test executed with failsafe fails.
[ https://issues.jenkins-ci.org/browse/JENKINS-12869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162551#comment-162551 ] Miquel Martin commented on JENKINS-12869: - Hi guys, I'd like to support this discussion. I agree that this behavior is inconsistent. Does anyone have an explanation? > Maven Build fails when integration/system test executed with failsafe fails. > > > Key: JENKINS-12869 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12869 > Project: Jenkins > Issue Type: Bug > Components: junit >Affects Versions: current >Reporter: Stefan Penndorf > > As described in this > [comment|https://issues.jenkins-ci.org/browse/JENKINS-4229?focusedCommentId=151372&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-151372] > jenkins behaves differently when executing tests with surefire or failsafe: > If a test executed with surefire fails the build continues and will be > "unstable", if the same test is executed with failsafe the build fails > completely (build status "failed"). > Current behaviour: maven build (and jenkins build) fail if a test executed > with failsafe fails. > Expected behaviour: maven build succeeds and jenkins build will be "unstable" > if a test executed with failsafe fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13711) Official Redhat yum repo (and mirrors) missing required repomd.xml
Steve Koppelman created JENKINS-13711:
-
Summary: Official Redhat yum repo (and mirrors) missing required
repomd.xml
Key: JENKINS-13711
URL: https://issues.jenkins-ci.org/browse/JENKINS-13711
Project: Jenkins
Issue Type: Bug
Components: infrastructure
Affects Versions: current
Reporter: Steve Koppelman
The yum repo at http://pkg.jenkins-ci.org/redhat is missing the yum metadata,
which should be located in {{repodata/repomd.xml}} relative to the base of the
repo.
Without this file, many yum operations, including installs, fail. In our case,
we use Red Hat Satellite to replicate repos for intranet use, as individual
nodes cannot install software directly over the internet. Replication via the
reposync utility fails because this metadata file is not present.
A yum repo is more than a directory of package files. It also serves an index
containing package metadata so that client systems can check for updates and
resolve dependencies without downloading the packages themselves.
Please generate the {{repodata/}} directory and its constituent files.. and
regenerate the files whenever new RPMs are released. This is usually done with
the {{createrepo}} utility either directly or as part of the publish process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13711) Official Redhat yum repo (and mirrors) missing required repomd.xml
[
https://issues.jenkins-ci.org/browse/JENKINS-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Koppelman updated JENKINS-13711:
--
Description:
The yum repo at http://pkg.jenkins-ci.org/redhat is missing the yum metadata,
which IIRC should be located in {{repodata/repomd.xml}} relative to the base of
the repo.
Without this file, many yum operations, including installs, fail. In our case,
we use Red Hat Satellite to replicate repos for intranet use, as individual
nodes cannot install software directly over the internet. Replication via the
reposync utility fails because this metadata file is not present.
A yum repo is more than a directory of package files. It also serves an index
containing package metadata so that client systems can check for updates and
resolve dependencies without downloading the packages themselves.
Please generate the {{repodata/}} directory and its constituent files.. and
regenerate the files whenever new RPMs are released. This is usually done with
the {{createrepo}} utility either directly or as part of the publish process.
was:
The yum repo at http://pkg.jenkins-ci.org/redhat is missing the yum metadata,
which should be located in {{repodata/repomd.xml}} relative to the base of the
repo.
Without this file, many yum operations, including installs, fail. In our case,
we use Red Hat Satellite to replicate repos for intranet use, as individual
nodes cannot install software directly over the internet. Replication via the
reposync utility fails because this metadata file is not present.
A yum repo is more than a directory of package files. It also serves an index
containing package metadata so that client systems can check for updates and
resolve dependencies without downloading the packages themselves.
Please generate the {{repodata/}} directory and its constituent files.. and
regenerate the files whenever new RPMs are released. This is usually done with
the {{createrepo}} utility either directly or as part of the publish process.
> Official Redhat yum repo (and mirrors) missing required repomd.xml
> --
>
> Key: JENKINS-13711
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13711
> Project: Jenkins
> Issue Type: Bug
> Components: infrastructure
>Affects Versions: current
>Reporter: Steve Koppelman
> Labels: website, yum
>
> The yum repo at http://pkg.jenkins-ci.org/redhat is missing the yum metadata,
> which IIRC should be located in {{repodata/repomd.xml}} relative to the base
> of the repo.
> Without this file, many yum operations, including installs, fail. In our
> case, we use Red Hat Satellite to replicate repos for intranet use, as
> individual nodes cannot install software directly over the internet.
> Replication via the reposync utility fails because this metadata file is not
> present.
> A yum repo is more than a directory of package files. It also serves an index
> containing package metadata so that client systems can check for updates and
> resolve dependencies without downloading the packages themselves.
> Please generate the {{repodata/}} directory and its constituent files.. and
> regenerate the files whenever new RPMs are released. This is usually done
> with the {{createrepo}} utility either directly or as part of the publish
> process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162552#comment-162552 ] Kohsuke Kawaguchi commented on JENKINS-11381: - I was ablt to reproduce [Alexsei's problem|https://issues.jenkins-ci.org/browse/JENKINS-11381?focusedCommentId=162505&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-162505] by checking out from 1.7 subversion server to 1.7 working copy format via svn:// protocol. Looking into it. > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162553#comment-162553 ] Kohsuke Kawaguchi commented on JENKINS-11381: - For those who are reporting issues with 1.40 RC, please also report: * version of the Subversion server (>=1.7 or <1.7?) * working copy format you set in the global configuration * Subversion access protocol > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13712) kill running project raises InterruptedException which is not properly handled
linfa zhu created JENKINS-13712: --- Summary: kill running project raises InterruptedException which is not properly handled Key: JENKINS-13712 URL: https://issues.jenkins-ci.org/browse/JENKINS-13712 Project: Jenkins Issue Type: Bug Components: core Reporter: linfa zhu Priority: Minor Could we handle the following annoying message when the project is killed manually? INFO: ondemand_qa_qpiga #136 aborted java.lang.InterruptedException at java.lang.Object.wait(Native Method) at hudson.remoting.Request.call(Request.java:127) at hudson.remoting.Channel.call(Channel.java:681) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) at $Proxy42.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:859) at hudson.Launcher$ProcStarter.join(Launcher.java:345) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:82) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) at hudson.model.Build$RunnerImpl.build(Build.java:178) at hudson.model.Build$RunnerImpl.doRun(Build.java:139) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1409) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13677) Active Direcoty Plugin not encrypted - FINE: Failed to start TLS. Authentication will be done via plain-text LDAP
[ https://issues.jenkins-ci.org/browse/JENKINS-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162554#comment-162554 ] Jolly E commented on JENKINS-13677: --- Yes. I use LDAPS for other systems authenticating against the same directory. I just haven't been able to find documentation about how to make the active directory plugin recognize the ssl certificates that encrypt it. I added the certs to the keystore that does the ssl encryption for the jenkins ( --httpsPort=8443 --httpsKeyStore=/var/lib/jenkins/.keystore --httpsKeyStorePassword=*** ) as well as to the /etc/pki/java/cacerts keystore. > Active Direcoty Plugin not encrypted - FINE: Failed to start TLS. > Authentication will be done via plain-text LDAP > - > > Key: JENKINS-13677 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13677 > Project: Jenkins > Issue Type: Task > Components: active-directory > Environment: rhel 6 connecting to active directory >Reporter: Jolly E >Priority: Minor > Labels: LDAP, LDAPS, SSL, active_directory,, encryption, > plain-text, tls > > FINE: Failed to start TLS. Authentication will be done via plain-text LDAP > javax.naming.CommunicationException: Remote host closed connection during > handshake [Root exception is javax.net.ssl.SSLHandshakeException: Remote host > closed connection during handshake] > at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3204) > at > hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DesciprotrImpl.bind(ActiveDirectorySecurityRealm.java:400) > at > hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DesciprotrImpl.bind(ActiveDirectorySecurityRealm.java:357) > at > hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:275) > at > hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:180) > at > hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:133) > at > org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:119) > at > org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:195) > at > org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:45) > at > org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:71) > at > org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:252) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) > at > hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) > at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) > at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) > at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) > at > hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) > at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) > at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) > at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) > at > winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) > at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) > at > java.util
[JIRA] (JENKINS-13713) disconnect a slave raises a IOException which is not properly handled
linfa zhu created JENKINS-13713: --- Summary: disconnect a slave raises a IOException which is not properly handled Key: JENKINS-13713 URL: https://issues.jenkins-ci.org/browse/JENKINS-13713 Project: Jenkins Issue Type: Bug Components: core Reporter: linfa zhu Priority: Minor Hi Since the disconnect is on purpose, could we handle the exception properly? thanks. SEVERE: I/O error in channel murphy java.io.IOException: Unexpected termination of the channel at hudson.remoting.Channel$ReaderThread.run(Channel.java:1133) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1127) May 8, 2012 12:11:12 PM hudson.remoting.Channel$ReaderThread run SEVERE: I/O error in channel murphy java.io.IOException: Unexpected termination of the channel at hudson.remoting.Channel$ReaderThread.run(Channel.java:1133) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1127) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11933) Subversion plugin doesn't probably work correctly with svn server version 1.7.1
[
https://issues.jenkins-ci.org/browse/JENKINS-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162555#comment-162555
]
Kohsuke Kawaguchi commented on JENKINS-11933:
-
Thanks centic for digging deeper into this. It sounds like a work around is to
avoid using that particular overloaded form of the doList method so that we can
pass in {{SVNDepth.IMMEDIATES}}?
> Subversion plugin doesn't probably work correctly with svn server version
> 1.7.1
> ---
>
> Key: JENKINS-11933
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11933
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
>Affects Versions: current
> Environment: svn server 1.7.1
> ubuntu
>Reporter: Nikita Aznauryan
>Priority: Blocker
> Labels: plugin
> Attachments: 0001-imported-1.3.7.patch,
> 0002-Adjust-version-number-in-pom.patch,
> 0003-update-version-and-add-second-maven-repository-to-ge.patch,
> 0005_subversion_plugin_svnkit_1_3_7.patch, subversion-svnkit-1.7.4.hpi,
> subversion.hpi
>
>
> I use usernames in my svn path like:
> svn+ssh://jenkins@somepath
> but I get a warning "... doesn't exist in the repository"
> I think it started after svn server has been updated to 1.7.1 version
> It worked fine before.
> Subversion pooling log :
> Started on Nov 30, 2011 8:11:31 PM
> Location 'svn+ssh://jenkins@path' does not exist
> One or more repository locations do not exist anymore for
> hudson.model.FreeStyleProject@3937bf4[], project will be disabled.
> Done. Took 1.3 sec
> No changes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kohsuke Kawaguchi updated JENKINS-11381: Attachment: subversion.hpi Attached 1.40 RC2 built from rev.40558 in the repository. > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi, subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162556#comment-162556 ] Kohsuke Kawaguchi edited comment on JENKINS-11381 at 5/8/12 5:17 PM: - [Attached 1.40 RC2|https://issues.jenkins-ci.org/secure/attachment/21802/subversion.hpi] built from rev.40558 in the repository. This version fixes the checkout failure problem with 1.7 server + 1.7 working copy. was (Author: kohsuke): Attached 1.40 RC2 built from rev.40558 in the repository. > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi, subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kohsuke Kawaguchi updated JENKINS-11381: Attachment: subversion.hpi And this is 1.40 RC3 that fixes the "list tags/branches" parameter problem. From the repository revision 40560. > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi, subversion.hpi, subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162557#comment-162557 ] Kohsuke Kawaguchi edited comment on JENKINS-11381 at 5/8/12 5:33 PM: - And [this is 1.40 RC3|https://issues.jenkins-ci.org/secure/attachment/21803/subversion.hpi] that fixes the "list tags/branches" parameter problem. From the repository revision 40560. was (Author: kohsuke): And this is 1.40 RC3 that fixes the "list tags/branches" parameter problem. From the repository revision 40560. > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Priority: Blocker > Attachments: subversion.hpi, subversion.hpi, subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11933) Subversion plugin doesn't probably work correctly with svn server version 1.7.1
[ https://issues.jenkins-ci.org/browse/JENKINS-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162558#comment-162558 ] dogfood commented on JENKINS-11933: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/yellow.png! [plugins_subversion #154|http://ci.jenkins-ci.org/job/plugins_subversion/154/] Added a test case for JENKINS-11933. (Revision 40560) [JENKINS-11933] tags and branches are now listed correctly with 1.7 This works around http://issues.tmatesoft.com/issue/SVNKIT-248 (Revision 40559) Result = UNSTABLE kohsuke : Files : * /trunk/hudson/plugins/subversion/src/test/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterDefinitionTest.java * /trunk/hudson/plugins/subversion/src/test/resources/hudson/scm/listtagsparameter * /trunk/hudson/plugins/subversion/src/test/resources/hudson/scm/listtagsparameter/JENKINS-11933.zip kohsuke : Files : * /trunk/hudson/plugins/subversion/src/main/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterDefinition.java > Subversion plugin doesn't probably work correctly with svn server version > 1.7.1 > --- > > Key: JENKINS-11933 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11933 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current > Environment: svn server 1.7.1 > ubuntu >Reporter: Nikita Aznauryan >Priority: Blocker > Labels: plugin > Attachments: 0001-imported-1.3.7.patch, > 0002-Adjust-version-number-in-pom.patch, > 0003-update-version-and-add-second-maven-repository-to-ge.patch, > 0005_subversion_plugin_svnkit_1_3_7.patch, subversion-svnkit-1.7.4.hpi, > subversion.hpi > > > I use usernames in my svn path like: > svn+ssh://jenkins@somepath > but I get a warning "... doesn't exist in the repository" > I think it started after svn server has been updated to 1.7.1 version > It worked fine before. > Subversion pooling log : > Started on Nov 30, 2011 8:11:31 PM > Location 'svn+ssh://jenkins@path' does not exist > One or more repository locations do not exist anymore for > hudson.model.FreeStyleProject@3937bf4[], project will be disabled. > Done. Took 1.3 sec > No changes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13701) Parameters lost on retry
[ https://issues.jenkins-ci.org/browse/JENKINS-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162559#comment-162559 ] Ken Garland edited comment on JENKINS-13701 at 5/8/12 6:22 PM: --- I've also just tried to setup a build that uses file based parameters with "Set environment variables through a file" and the parameters are not sent to the job at run time. Build > Execute shell > Command echo $temp_name [envfile] temp_name=test [workspace] $ /bin/sh -xe /tmp/hudson2757699259452188104.sh + echo As you can see, echo has nothing afterwards. was (Author: outspoken): I've also just tried to setup a build that uses file based parameters with "Set environment variables through a file" and the parameters are not sent to the job at run time. Build > Execute shell > Command echo $temp_name [envfile] temp_name=test [workspace] $ /bin/sh -xe /tmp/hudson2757699259452188104.sh + echo As you can see, echo has nothing afterwards. This works on the first run. > Parameters lost on retry > > > Key: JENKINS-13701 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13701 > Project: Jenkins > Issue Type: Bug > Components: naginator >Affects Versions: current > Environment: Jenkins 1.463, Naginator 1.6.1, Parameterized Trigger > 2.14 >Reporter: Ken Garland >Assignee: Nayan Hajratwala > Labels: naginator, plugin, trigger > > Parameters are not passed onto newly started Naginator jobs. > Started by Naginator > [EnvInject] - Loading node environment variables. > Building in workspace /root/.jenkins/jobs/test/workspace > Checkout:workspace / /root/.jenkins/jobs/test/workspace - > hudson.remoting.LocalChannel@2a2bfd5 > Using strategy: Default > [workspace] $ /bin/sh -xe /tmp/hudson3453253707221002170.sh > + python test.py --hostname > There should be a value after "--hostname" as it is in the original build > before failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13701) Parameters lost on retry
[ https://issues.jenkins-ci.org/browse/JENKINS-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162559#comment-162559 ] Ken Garland commented on JENKINS-13701: --- I've also just tried to setup a build that uses file based parameters with "Set environment variables through a file" and the parameters are not sent to the job at run time. Build > Execute shell > Command echo $temp_name [envfile] temp_name=test [workspace] $ /bin/sh -xe /tmp/hudson2757699259452188104.sh + echo As you can see, echo has nothing afterwards. This works on the first run. > Parameters lost on retry > > > Key: JENKINS-13701 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13701 > Project: Jenkins > Issue Type: Bug > Components: naginator >Affects Versions: current > Environment: Jenkins 1.463, Naginator 1.6.1, Parameterized Trigger > 2.14 >Reporter: Ken Garland >Assignee: Nayan Hajratwala > Labels: naginator, plugin, trigger > > Parameters are not passed onto newly started Naginator jobs. > Started by Naginator > [EnvInject] - Loading node environment variables. > Building in workspace /root/.jenkins/jobs/test/workspace > Checkout:workspace / /root/.jenkins/jobs/test/workspace - > hudson.remoting.LocalChannel@2a2bfd5 > Using strategy: Default > [workspace] $ /bin/sh -xe /tmp/hudson3453253707221002170.sh > + python test.py --hostname > There should be a value after "--hostname" as it is in the original build > before failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13398) support for starteam cache agents
[ https://issues.jenkins-ci.org/browse/JENKINS-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162560#comment-162560 ] pauldawg commented on JENKINS-13398: Looks good, mistafunk. Programming for a cache agent isn't very complex. Off the top of my head I might suggest a couple more things to look into: 1) auto-detecting a cache agent, 2) verifying that MPX is available first, 3) allowing both method signature with and without cache agent, for compatibility with other branches or offline custom development, 4) console output to show status of cache, 5) console output to show cache agent checkout statistics. > support for starteam cache agents > - > > Key: JENKINS-13398 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13398 > Project: Jenkins > Issue Type: Improvement > Components: starteam >Affects Versions: current >Reporter: mistafunk >Assignee: jan_ruzicka >Priority: Minor > > it would be nice to have support for starteam cache agents, this would > accelerate checkouts quite a bit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13398) support for starteam cache agents
[ https://issues.jenkins-ci.org/browse/JENKINS-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162561#comment-162561 ] pauldawg commented on JENKINS-13398: As to Jan's question re: "issues with connections from a distant node vs. master", not sure if I understand the question, but here's what I know. A remote cache agent should be on the LAN where the client is located, or if you are on a build server, it can be installed on the client machine itself (and if necessary, filtered to just the projects you are interested in). Whether it connects to a distant server and root cache is irrelevant, as the improvements achieved by connecting to the local remote cache are going to add benefit, and StarTeam automatically figures out on a case by case basis whether it is more efficient to check out from the server or from the local cache (usually the latter, unless the file is not yet cached). Connecting to a root cache is not actually an option; though you won't get any errors, the root cache does not serve clients, it only serves remote caches. The things to keep in mind when thinking about distance are: if the target site is not in the internal network (e.g. site to site VPN), they will need to subscribe to an MPX profile with an address that is resolvable at the target site (you can do this with a DNS entry, cname, host.ini, etc.), and then the remote cache at that site has to be configured to use those same entries, as the true IP will not be visible at the remote site. Aside from that I don't know of any specific issues to comment on. Perhaps I've misunderstood your question though, so please clarify if needed. > support for starteam cache agents > - > > Key: JENKINS-13398 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13398 > Project: Jenkins > Issue Type: Improvement > Components: starteam >Affects Versions: current >Reporter: mistafunk >Assignee: jan_ruzicka >Priority: Minor > > it would be nice to have support for starteam cache agents, this would > accelerate checkouts quite a bit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13714) Drag and drop handle missing from transfer sets
bap created JENKINS-13714: - Summary: Drag and drop handle missing from transfer sets Key: JENKINS-13714 URL: https://issues.jenkins-ci.org/browse/JENKINS-13714 Project: Jenkins Issue Type: Bug Components: publish-over-ssh Reporter: bap Assignee: bap Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13398) support for starteam cache agents
[ https://issues.jenkins-ci.org/browse/JENKINS-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162562#comment-162562 ] jan_ruzicka commented on JENKINS-13398: --- node vs. master was meant as jenkins node vs jenkins master. The jenkins master stores configuration and some details. Nodes do the work and don't have to be on same computer. Nodes can be on a different lan, they can be a different OS ... . > support for starteam cache agents > - > > Key: JENKINS-13398 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13398 > Project: Jenkins > Issue Type: Improvement > Components: starteam >Affects Versions: current >Reporter: mistafunk >Assignee: jan_ruzicka >Priority: Minor > > it would be nice to have support for starteam cache agents, this would > accelerate checkouts quite a bit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13398) support for starteam cache agents
[ https://issues.jenkins-ci.org/browse/JENKINS-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162563#comment-162563 ] jan_ruzicka commented on JENKINS-13398: --- Is it possible to have setup without cache and still work with the changes[1]? Can there be unit test cases for both setup with cache and without? Main issue is a backward compatibility ... (There were some requests for support of StarTeam 6.0) [1] https://github.com/mistafunk/starteam-plugin/commit/58249bf78db0fc25e36ea8141b2571072bc19f0e > support for starteam cache agents > - > > Key: JENKINS-13398 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13398 > Project: Jenkins > Issue Type: Improvement > Components: starteam >Affects Versions: current >Reporter: mistafunk >Assignee: jan_ruzicka >Priority: Minor > > it would be nice to have support for starteam cache agents, this would > accelerate checkouts quite a bit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13714) Drag and drop handle missing from transfer sets
[ https://issues.jenkins-ci.org/browse/JENKINS-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162564#comment-162564 ] SCM/JIRA link daemon commented on JENKINS-13714: Code changed in jenkins User: bap2000 Path: src/main/resources/jenkins/plugins/publish_over_ssh/BapSshPublisher/config.jelly http://jenkins-ci.org/commit/publish-over-ssh-plugin/f06bfde98463ef2a24b52eb826958007a29a6d59 Log: Restore the drag and drop handle for transfer sets [FIXED JENKINS-13714] > Drag and drop handle missing from transfer sets > --- > > Key: JENKINS-13714 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13714 > Project: Jenkins > Issue Type: Bug > Components: publish-over-ssh >Reporter: bap >Assignee: bap >Priority: Minor > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13714) Drag and drop handle missing from transfer sets
[ https://issues.jenkins-ci.org/browse/JENKINS-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13714. Resolution: Fixed > Drag and drop handle missing from transfer sets > --- > > Key: JENKINS-13714 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13714 > Project: Jenkins > Issue Type: Bug > Components: publish-over-ssh >Reporter: bap >Assignee: bap >Priority: Minor > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13693) Add DefaultExcludes boolean option to transfer set
[ https://issues.jenkins-ci.org/browse/JENKINS-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bap reassigned JENKINS-13693: - Assignee: bap > Add DefaultExcludes boolean option to transfer set > -- > > Key: JENKINS-13693 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13693 > Project: Jenkins > Issue Type: Improvement > Components: publish-over-ssh >Affects Versions: current >Reporter: Adrian Smith >Assignee: bap >Priority: Minor > > Publish-over-ssh follows the Ant patterns > (http://ant.apache.org/manual/dirtasks.html#patterns) but does not allow me > to set the defaultexcludes="no" attribute. > I want to send all my .git* files to the remote system. > I know this can be bad practice, but I imagine it's a pretty common request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13460) Environment variables not explanded for "Remote Directory" configuration
[
https://issues.jenkins-ci.org/browse/JENKINS-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bap resolved JENKINS-13460.
---
Resolution: Won't Fix
> Environment variables not explanded for "Remote Directory" configuration
>
>
> Key: JENKINS-13460
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13460
> Project: Jenkins
> Issue Type: Bug
> Components: publish-over-ssh
>Reporter: Bertrand Latinville
>Assignee: bap
>Priority: Minor
> Labels: deployment, plugin
>
> I'm using publish over ssh to send file on a remote folder
> and Exec commands.
> As the folder where I put the files may change in the future I defined a
> Jenkins environment variable: REMOTE_LOCATION.
> I'd like to use this variable in SSH publish over configuration and in the
> Exec command of the job.
> I configured ssh publish over plugin with Remote Directory set to
> ${REMOTE_LOCATION}
> I get this error :
> ERROR: Exception when publishing, exception message [Failed to change to
> remote directory [${REMOTE_LOCATION}]]
> Build step 'Send build artifacts over SSH' changed build result to UNSTABLE
> I checked that the variable is set properly by echo ${REMOTE_LOCATION} in the
> Exec command.
> Variables should be expanded in the "Remote Directory" configuration field.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13460) Environment variables not explanded for "Remote Directory" configuration
[
https://issues.jenkins-ci.org/browse/JENKINS-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bap closed JENKINS-13460.
-
> Environment variables not explanded for "Remote Directory" configuration
>
>
> Key: JENKINS-13460
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13460
> Project: Jenkins
> Issue Type: Bug
> Components: publish-over-ssh
>Reporter: Bertrand Latinville
>Assignee: bap
>Priority: Minor
> Labels: deployment, plugin
>
> I'm using publish over ssh to send file on a remote folder
> and Exec commands.
> As the folder where I put the files may change in the future I defined a
> Jenkins environment variable: REMOTE_LOCATION.
> I'd like to use this variable in SSH publish over configuration and in the
> Exec command of the job.
> I configured ssh publish over plugin with Remote Directory set to
> ${REMOTE_LOCATION}
> I get this error :
> ERROR: Exception when publishing, exception message [Failed to change to
> remote directory [${REMOTE_LOCATION}]]
> Build step 'Send build artifacts over SSH' changed build result to UNSTABLE
> I checked that the variable is set properly by echo ${REMOTE_LOCATION} in the
> Exec command.
> Variables should be expanded in the "Remote Directory" configuration field.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12891) Use a temporary name for the uploading files
[
https://issues.jenkins-ci.org/browse/JENKINS-12891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bap resolved JENKINS-12891.
---
Resolution: Won't Fix
> Use a temporary name for the uploading files
>
>
> Key: JENKINS-12891
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12891
> Project: Jenkins
> Issue Type: Improvement
> Components: publish-over-ssh
>Affects Versions: current
>Reporter: Artem V. Navrotskiy
>Assignee: bap
>
> Now when downloading large files for a long time at the destination may not
> be a complete file. This can lead to various problems.
> To avoid this problem you need to load it under a temporary name and then
> rename the.
> For example:
> {code}
> sftp> put bigfile.bin bigfile.bin~tmp123
> sftp> rename bigfile.bin~tmp123 bigfile.bin
> {code}
> Now you need to do:
> - Script to rename a file in the working directory;
> - Upload renamed files by ssh;
> - Using "Exec command" to change cuurent directory to upload directory
> (JENKINS-12890) and rename files back.
> This workaround looks like ugly :(
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12890) Current path of "Exec command" is not related for "Remote directory"
[ https://issues.jenkins-ci.org/browse/JENKINS-12890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bap resolved JENKINS-12890. --- Resolution: Won't Fix > Current path of "Exec command" is not related for "Remote directory" > > > Key: JENKINS-12890 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12890 > Project: Jenkins > Issue Type: Bug > Components: publish-over-ssh >Affects Versions: current >Reporter: Artem V. Navrotskiy >Assignee: bap > > Scripts, added by "Exec command" started in remote user home path. > You can not specify a script that runs in the directory where the files were > uploaded without explicitly specifying the full path in the script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13714) Drag and drop handle missing from transfer sets
[ https://issues.jenkins-ci.org/browse/JENKINS-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bap closed JENKINS-13714. - > Drag and drop handle missing from transfer sets > --- > > Key: JENKINS-13714 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13714 > Project: Jenkins > Issue Type: Bug > Components: publish-over-ssh >Reporter: bap >Assignee: bap >Priority: Minor > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11933) Subversion plugin doesn't probably work correctly with svn server version 1.7.1
[ https://issues.jenkins-ci.org/browse/JENKINS-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162565#comment-162565 ] centic commented on JENKINS-11933: -- Ad [\[1\]|https://issues.jenkins-ci.org/browse/JENKINS-11933?focusedCommentId=162555&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-162555], yes, it looks like a regression that svnkit changed behavior for the doList() method that was used before, but the other form that is available allows to work around it nicely. > Subversion plugin doesn't probably work correctly with svn server version > 1.7.1 > --- > > Key: JENKINS-11933 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11933 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current > Environment: svn server 1.7.1 > ubuntu >Reporter: Nikita Aznauryan >Priority: Blocker > Labels: plugin > Attachments: 0001-imported-1.3.7.patch, > 0002-Adjust-version-number-in-pom.patch, > 0003-update-version-and-add-second-maven-repository-to-ge.patch, > 0005_subversion_plugin_svnkit_1_3_7.patch, subversion-svnkit-1.7.4.hpi, > subversion.hpi > > > I use usernames in my svn path like: > svn+ssh://jenkins@somepath > but I get a warning "... doesn't exist in the repository" > I think it started after svn server has been updated to 1.7.1 version > It worked fine before. > Subversion pooling log : > Started on Nov 30, 2011 8:11:31 PM > Location 'svn+ssh://jenkins@path' does not exist > One or more repository locations do not exist anymore for > hudson.model.FreeStyleProject@3937bf4[], project will be disabled. > Done. Took 1.3 sec > No changes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13315) Build Keeper plugin: support keeping all unstable, failing runs
[ https://issues.jenkins-ci.org/browse/JENKINS-13315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bap closed JENKINS-13315. - > Build Keeper plugin: support keeping all unstable, failing runs > --- > > Key: JENKINS-13315 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13315 > Project: Jenkins > Issue Type: Improvement > Components: build-keeper-plugin >Affects Versions: current >Reporter: Steve Roth >Assignee: bap >Priority: Minor > > First off, thanks for this very helpful plugin. > I use this plugin to monitor for systemic stability issues and keep the > relevant build artifacts when issues are found. Then when I have time, I > review these artifacts and identify the most common issues. > One feature which would really help this use-case, which I think may be a > minor change, would be to add > 'keep all unstable and failing builds'. > There may also be use-cases for: > 'keep all unstable builds'. > 'keep all failing builds'. > But for our particular case, we'd ideally want to be able to use 'keep all > unstable and failing builds'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13715) User email suffixes are getting overwritten with the with the subversion repo UUID
David Pattison created JENKINS-13715: Summary: User email suffixes are getting overwritten with the with the subversion repo UUID Key: JENKINS-13715 URL: https://issues.jenkins-ci.org/browse/JENKINS-13715 Project: Jenkins Issue Type: Bug Components: email-ext, subversion Environment: Ubuntu 8.04 Jenkins: 1.447.1 Plugins: javadoc 1.0 truefalse maven-plugin1.447.1 truefalse ant 1.1 truefalse analysis-core 1.18truefalse pmd 3.14truefalse cvs 1.6 truefalse ci-game 1.18truefalse instant-messaging 1.21truefalse ircbot 2.18truefalse subversion 1.23truetrue ssh-slaves 0.21truefalse claim 1.7 truefalse translation 1.8 truefalse bugzilla1.4 false false WebSVN2 0.9 truefalse email-ext 2.19truefalse parameterized-trigger 2.12truefalse git 1.1.12 truefalse repository 0.7 truefalse bruceschneier 0.1 truefalse global-build-stats 1.0 truefalse rebuild 1.9 truefalse greenballs 1.10truefalse log-parser 1.0.8 truefalse schedule-failed-builds 1.1 false false analysis-collector 1.12truefalse radiatorviewplugin 1.13truefalse xunit 1.5 truefalse Reporter: David Pattison Several users on the system can't get any build emails. The email keep getting set to "davidp@046000e8-c612-472f-bb51-fe359d1450d5" For certain users. * This only happens to users who have configs set, in $JENKINS_HOME/users/user-name.xml * The number at the end is the Subversion UUID. * Removing/deleting/modifying the user configs does not work. This is very similar to the https://issues.jenkins-ci.org/browse/JENKINS-11731, but only applies to some users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13202) Artifact archiving from an ssh slave fails if symlinks are present
[
https://issues.jenkins-ci.org/browse/JENKINS-13202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162566#comment-162566
]
SCM/JIRA link daemon commented on JENKINS-13202:
Code changed in jenkins
User: David Reiss
Path:
changelog.html
core/src/main/java/hudson/FilePath.java
core/src/test/java/hudson/FilePathTest.java
http://jenkins-ci.org/commit/jenkins/e15b2e19e394f5d63183f01a2e72a14115a0c370
Log:
[FIXED JENKINS-13202] Don't set mtime or mode on symlinks
Previously, the untar code tries to set the last modified time and mode
on every untarred file. However, if the tar contains a broken symlink,
or a symlink that points to a file that has not been untarred yet, the
time/mode setting would fail on the broken symlink.
Symlinks don't have meaningful modified times or modes of their own, so
only set these values on non-symlinks.
Rename the file "a" in the test to expose the bug.
> Artifact archiving from an ssh slave fails if symlinks are present
> --
>
> Key: JENKINS-13202
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13202
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
> Environment: Slave must be a "Unix via SSH" slave. I suspect the
> master must be Unix-based also. I tested with both the master and slave on
> Linux.
>Reporter: David Reiss
> Labels: artifact
>
> When archiving artifacts from a job executed on a "Unix via SSH" slave, if a
> symlink is present and archived before its target, the archiving will fail.
> It looks like the master is trying to chmod the local symlink (because it has
> executable permissions stored in the tar used to do the remote copy), but
> that fails because the target doesn't exist yet, and the exception aborts the
> archiving. I think the solution is to just not chmod symlinks, since they
> don't have modes of their own. This was a regression from 1.455 to 1.456. I
> suspect the fixes for JENKINS-9118 are the cause.
> To reproduce this problem, install the Jenkins master on a Linux machine and
> add a "Unix via SSH" slave that is also a Linux machine. Create a job with
> the following build script:
> {noformat}
> rm -rf stuff
> mkdir stuff
> cd stuff
> touch zzfile
> ln -s zzfile aafile
> ln -s zzfile bbfile
> {noformat}
> Restrict this project to build on the slave. Set up archiving for "stuff/*".
> Run the job. The job will complete successfully, but archiving will abort
> partway though with a stack trace in the console.
> {noformat}
> Archiving artifacts
> ERROR: Failed to archive artifacts: stuff/*
> hudson.util.IOException2: Failed to extract
> /tmp/jenkins-slave-home/workspace/create_symlinks/stuff/*
> at hudson.FilePath.readFromTar(FilePath.java:1817)
> at hudson.FilePath.copyRecursiveTo(FilePath.java:1729)
> at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656)
> at hudson.model.Build$RunnerImpl.post2(Build.java:162)
> at
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
> at hudson.model.Run.run(Run.java:1435)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> Caused by: java.io.IOException: Failed to chmod
> /tmp/jenkins-home/jobs/create_symlinks/builds/2012-03-21_16-53-15/archive/stuff/aafile
> : No such file or directory
> at hudson.FilePath._chmod(FilePath.java:1248)
> at hudson.FilePath.readFromTar(FilePath.java:1813)
> ... 12 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13202) Artifact archiving from an ssh slave fails if symlinks are present
[
https://issues.jenkins-ci.org/browse/JENKINS-13202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
SCM/JIRA link daemon resolved JENKINS-13202.
Resolution: Fixed
> Artifact archiving from an ssh slave fails if symlinks are present
> --
>
> Key: JENKINS-13202
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13202
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
> Environment: Slave must be a "Unix via SSH" slave. I suspect the
> master must be Unix-based also. I tested with both the master and slave on
> Linux.
>Reporter: David Reiss
> Labels: artifact
>
> When archiving artifacts from a job executed on a "Unix via SSH" slave, if a
> symlink is present and archived before its target, the archiving will fail.
> It looks like the master is trying to chmod the local symlink (because it has
> executable permissions stored in the tar used to do the remote copy), but
> that fails because the target doesn't exist yet, and the exception aborts the
> archiving. I think the solution is to just not chmod symlinks, since they
> don't have modes of their own. This was a regression from 1.455 to 1.456. I
> suspect the fixes for JENKINS-9118 are the cause.
> To reproduce this problem, install the Jenkins master on a Linux machine and
> add a "Unix via SSH" slave that is also a Linux machine. Create a job with
> the following build script:
> {noformat}
> rm -rf stuff
> mkdir stuff
> cd stuff
> touch zzfile
> ln -s zzfile aafile
> ln -s zzfile bbfile
> {noformat}
> Restrict this project to build on the slave. Set up archiving for "stuff/*".
> Run the job. The job will complete successfully, but archiving will abort
> partway though with a stack trace in the console.
> {noformat}
> Archiving artifacts
> ERROR: Failed to archive artifacts: stuff/*
> hudson.util.IOException2: Failed to extract
> /tmp/jenkins-slave-home/workspace/create_symlinks/stuff/*
> at hudson.FilePath.readFromTar(FilePath.java:1817)
> at hudson.FilePath.copyRecursiveTo(FilePath.java:1729)
> at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656)
> at hudson.model.Build$RunnerImpl.post2(Build.java:162)
> at
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
> at hudson.model.Run.run(Run.java:1435)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> Caused by: java.io.IOException: Failed to chmod
> /tmp/jenkins-home/jobs/create_symlinks/builds/2012-03-21_16-53-15/archive/stuff/aafile
> : No such file or directory
> at hudson.FilePath._chmod(FilePath.java:1248)
> at hudson.FilePath.readFromTar(FilePath.java:1813)
> ... 12 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13701) Parameters lost on retry
[ https://issues.jenkins-ci.org/browse/JENKINS-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nayan Hajratwala reassigned JENKINS-13701: -- Assignee: (was: Nayan Hajratwala) > Parameters lost on retry > > > Key: JENKINS-13701 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13701 > Project: Jenkins > Issue Type: Bug > Components: naginator >Affects Versions: current > Environment: Jenkins 1.463, Naginator 1.6.1, Parameterized Trigger > 2.14 >Reporter: Ken Garland > Labels: naginator, plugin, trigger > > Parameters are not passed onto newly started Naginator jobs. > Started by Naginator > [EnvInject] - Loading node environment variables. > Building in workspace /root/.jenkins/jobs/test/workspace > Checkout:workspace / /root/.jenkins/jobs/test/workspace - > hudson.remoting.LocalChannel@2a2bfd5 > Using strategy: Default > [workspace] $ /bin/sh -xe /tmp/hudson3453253707221002170.sh > + python test.py --hostname > There should be a value after "--hostname" as it is in the original build > before failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162567#comment-162567 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/analysis/core/BuildResult.java src/main/java/hudson/plugins/analysis/util/HtmlPrinter.java src/main/resources/hudson/plugins/analysis/Messages.properties src/main/resources/hudson/plugins/analysis/Messages_de.properties src/main/resources/hudson/plugins/analysis/Messages_fr.properties src/main/resources/hudson/plugins/analysis/Messages_ja.properties src/test/java/hudson/plugins/analysis/core/BuildResultTest.java http://jenkins-ci.org/commit/analysis-core-plugin/882d0579575d069b2e45e4528dd70bb2ccc68020 Log: [JENKINS-12424] Pulled up build result summary message to BuildResult. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162568#comment-162568 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: pom.xml src/main/java/hudson/plugins/dry/DryResult.java src/main/java/hudson/plugins/dry/ResultSummary.java src/main/resources/hudson/plugins/dry/Messages.properties src/main/resources/hudson/plugins/dry/Messages_de.properties src/main/resources/hudson/plugins/dry/Messages_ja.properties src/test/java/hudson/plugins/dry/ResultSummaryTest.java http://jenkins-ci.org/commit/dry-plugin/3b34bf609768117b4aa419de8b91bb7af8923ac9 Log: [JENKINS-12424] Use messages from base class. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162573#comment-162573 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/warnings/WarningsResult.java src/main/resources/hudson/plugins/warnings/Messages.properties src/main/resources/hudson/plugins/warnings/Messages_de.properties src/main/resources/hudson/plugins/warnings/Messages_fr.properties src/main/resources/hudson/plugins/warnings/Messages_ja.properties http://jenkins-ci.org/commit/warnings-plugin/a530b8e715536d3b5c3b040e0de569a303d0291f Log: [JENKINS-12424] Use messages from base class. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162572#comment-162572 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: pom.xml src/main/java/hudson/plugins/analysis/collector/AnalysisResult.java src/main/java/hudson/plugins/analysis/collector/AnalysisResultSummary.java src/main/resources/hudson/plugins/analysis/collector/Messages.properties src/main/resources/hudson/plugins/analysis/collector/Messages_de.properties src/main/resources/hudson/plugins/analysis/collector/Messages_ja.properties src/test/java/hudson/plugins/analysis/collector/ResultSummaryTest.java http://jenkins-ci.org/commit/analysis-collector-plugin/5743c8c7b9035e3c4e0a1d0543f8307f6469029c Log: [JENKINS-12424] Use messages from base class. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162571#comment-162571 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: pom.xml src/main/java/hudson/plugins/pmd/PmdResult.java src/main/java/hudson/plugins/pmd/ResultSummary.java src/main/resources/hudson/plugins/pmd/Messages.properties src/main/resources/hudson/plugins/pmd/Messages_de.properties src/main/resources/hudson/plugins/pmd/Messages_fr.properties src/main/resources/hudson/plugins/pmd/Messages_ja.properties src/test/java/hudson/plugins/pmd/ResultSummaryTest.java http://jenkins-ci.org/commit/pmd-plugin/933785d4f694c9bbbd07f18b17e8badf0dff4953 Log: [JENKINS-12424] Use messages from base class. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162570#comment-162570 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: plugin/pom.xml plugin/src/main/java/hudson/plugins/findbugs/FindBugsResult.java plugin/src/main/java/hudson/plugins/findbugs/ResultSummary.java plugin/src/main/resources/hudson/plugins/findbugs/Messages.properties plugin/src/main/resources/hudson/plugins/findbugs/Messages_de.properties plugin/src/main/resources/hudson/plugins/findbugs/Messages_ja.properties plugin/src/test/java/hudson/plugins/findbugs/ResultSummaryTest.java http://jenkins-ci.org/commit/findbugs-plugin/fbbb1fef2619c783f0ee49a652234cb127b737f4 Log: [JENKINS-12424] Use messages from base class. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162569#comment-162569 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: pom.xml src/main/java/hudson/plugins/checkstyle/CheckStyleResult.java src/main/java/hudson/plugins/checkstyle/ResultSummary.java src/main/resources/hudson/plugins/checkstyle/Messages.properties src/main/resources/hudson/plugins/checkstyle/Messages_de.properties src/main/resources/hudson/plugins/checkstyle/Messages_fr.properties src/main/resources/hudson/plugins/checkstyle/Messages_ja.properties src/test/java/hudson/plugins/checkstyle/ResultSummaryTest.java http://jenkins-ci.org/commit/checkstyle-plugin/c9863ac5e7a939f58897200225a724063555f08f Log: [JENKINS-12424] Use messages from base class. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13202) Artifact archiving from an ssh slave fails if symlinks are present
[
https://issues.jenkins-ci.org/browse/JENKINS-13202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162574#comment-162574
]
dogfood commented on JENKINS-13202:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_main_trunk #1710|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1710/]
[FIXED JENKINS-13202] Don't set mtime or mode on symlinks (Revision
e15b2e19e394f5d63183f01a2e72a14115a0c370)
Result = SUCCESS
Kohsuke Kawaguchi :
[e15b2e19e394f5d63183f01a2e72a14115a0c370|https://github.com/jenkinsci/jenkins/commit/e15b2e19e394f5d63183f01a2e72a14115a0c370]
Files :
* changelog.html
* core/src/main/java/hudson/FilePath.java
* core/src/test/java/hudson/FilePathTest.java
> Artifact archiving from an ssh slave fails if symlinks are present
> --
>
> Key: JENKINS-13202
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13202
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
> Environment: Slave must be a "Unix via SSH" slave. I suspect the
> master must be Unix-based also. I tested with both the master and slave on
> Linux.
>Reporter: David Reiss
> Labels: artifact
>
> When archiving artifacts from a job executed on a "Unix via SSH" slave, if a
> symlink is present and archived before its target, the archiving will fail.
> It looks like the master is trying to chmod the local symlink (because it has
> executable permissions stored in the tar used to do the remote copy), but
> that fails because the target doesn't exist yet, and the exception aborts the
> archiving. I think the solution is to just not chmod symlinks, since they
> don't have modes of their own. This was a regression from 1.455 to 1.456. I
> suspect the fixes for JENKINS-9118 are the cause.
> To reproduce this problem, install the Jenkins master on a Linux machine and
> add a "Unix via SSH" slave that is also a Linux machine. Create a job with
> the following build script:
> {noformat}
> rm -rf stuff
> mkdir stuff
> cd stuff
> touch zzfile
> ln -s zzfile aafile
> ln -s zzfile bbfile
> {noformat}
> Restrict this project to build on the slave. Set up archiving for "stuff/*".
> Run the job. The job will complete successfully, but archiving will abort
> partway though with a stack trace in the console.
> {noformat}
> Archiving artifacts
> ERROR: Failed to archive artifacts: stuff/*
> hudson.util.IOException2: Failed to extract
> /tmp/jenkins-slave-home/workspace/create_symlinks/stuff/*
> at hudson.FilePath.readFromTar(FilePath.java:1817)
> at hudson.FilePath.copyRecursiveTo(FilePath.java:1729)
> at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656)
> at hudson.model.Build$RunnerImpl.post2(Build.java:162)
> at
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
> at hudson.model.Run.run(Run.java:1435)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> Caused by: java.io.IOException: Failed to chmod
> /tmp/jenkins-home/jobs/create_symlinks/builds/2012-03-21_16-53-15/archive/stuff/aafile
> : No such file or directory
> at hudson.FilePath._chmod(FilePath.java:1248)
> at hudson.FilePath.readFromTar(FilePath.java:1813)
> ... 12 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13716) Default graph configuration for project is not read
Ulli Hafner created JENKINS-13716: - Summary: Default graph configuration for project is not read Key: JENKINS-13716 URL: https://issues.jenkins-ci.org/browse/JENKINS-13716 Project: Jenkins Issue Type: Bug Components: warnings Reporter: Ulli Hafner Assignee: Ulli Hafner Priority: Minor Seems that the defaults for the trend graph that are read from a file don not work anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162576#comment-162576 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/checkstyle/CheckStyleResultAction.java http://jenkins-ci.org/commit/checkstyle-plugin/f0fab6a73c1197d5f78b2493789c3e4ae9692f5b Log: [JENKINS-12424] Pulled up tool tips. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162575#comment-162575 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/analysis/core/AbstractResultAction.java http://jenkins-ci.org/commit/analysis-core-plugin/fde91c34942a51e50d8be0d2eba7df08ed52534b Log: [JENKINS-12424] Pulled up tool tips. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162577#comment-162577 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/dry/DryResultAction.java http://jenkins-ci.org/commit/dry-plugin/e0c7b51ab19fe8749a0be2b8d105d0c2f820d210 Log: [JENKINS-12424] Pulled up tool tips. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162579#comment-162579 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: plugin/src/main/java/hudson/plugins/findbugs/FindBugsResultAction.java http://jenkins-ci.org/commit/findbugs-plugin/09423284d787f23cd1397070c43303967a3451ce Log: [JENKINS-12424] Pulled up tool tips. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162581#comment-162581 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/analysis/collector/AnalysisResultAction.java http://jenkins-ci.org/commit/analysis-collector-plugin/6d57f9725542884510355622b84692b0ede612ea Log: [JENKINS-12424] Pulled up tool tips. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162582#comment-162582 ] dogfood commented on JENKINS-12424: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_analysis-core #10448|http://ci.jenkins-ci.org/job/plugins_analysis-core/10448/] [JENKINS-12424] Pulled up build result summary message to BuildResult. (Revision 882d0579575d069b2e45e4528dd70bb2ccc68020) Result = SUCCESS Ulli Hafner : Files : * src/main/resources/hudson/plugins/analysis/Messages_fr.properties * src/main/resources/hudson/plugins/analysis/Messages_de.properties * src/test/java/hudson/plugins/analysis/core/BuildResultTest.java * src/main/resources/hudson/plugins/analysis/Messages_ja.properties * src/main/resources/hudson/plugins/analysis/Messages.properties * src/main/java/hudson/plugins/analysis/util/HtmlPrinter.java * src/main/java/hudson/plugins/analysis/core/BuildResult.java > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162580#comment-162580 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/warnings/WarningsResultAction.java http://jenkins-ci.org/commit/warnings-plugin/27ced4879f77753a48b4ab60a7a0e09426758ef8 Log: [JENKINS-12424] Pulled up tool tips. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162578#comment-162578 ] SCM/JIRA link daemon commented on JENKINS-12424: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/pmd/PmdResultAction.java http://jenkins-ci.org/commit/pmd-plugin/4c0aed391e7f175bad887c3f2f35171b5802fc89 Log: [JENKINS-12424] Pulled up tool tips. > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162583#comment-162583 ] Ulli Hafner commented on JENKINS-12424: --- Integrated in !http://faktorzehn.org:8081/images/16x16/blue.png! [Jenkins Analysis Plug-ins (Compile) #495|http://faktorzehn.org:8081/job/Jenkins%20Analysis%20Plug-ins%20(Compile)/495/] [JENKINS-12424] Pulled up tool tips. (Revision fde91c34942a51e50d8be0d2eba7df08ed52534b) Result = SUCCESS > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162584#comment-162584 ] dogfood commented on JENKINS-12424: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_analysis-core #10449|http://ci.jenkins-ci.org/job/plugins_analysis-core/10449/] [JENKINS-12424] Pulled up tool tips. (Revision fde91c34942a51e50d8be0d2eba7df08ed52534b) Result = SUCCESS Ulli Hafner : Files : * src/main/java/hudson/plugins/analysis/core/AbstractResultAction.java > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162586#comment-162586 ] dogfood commented on JENKINS-12424: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_checkstyle #346|http://ci.jenkins-ci.org/job/plugins_checkstyle/346/] Result = SUCCESS > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162587#comment-162587 ] dogfood commented on JENKINS-12424: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_dry #349|http://ci.jenkins-ci.org/job/plugins_dry/349/] Result = SUCCESS > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162585#comment-162585 ] dogfood commented on JENKINS-12424: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_analysis-collector #354|http://ci.jenkins-ci.org/job/plugins_analysis-collector/354/] Result = SUCCESS > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162588#comment-162588 ] dogfood commented on JENKINS-12424: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_findbugs #420|http://ci.jenkins-ci.org/job/plugins_findbugs/420/] Result = SUCCESS > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162590#comment-162590 ] dogfood commented on JENKINS-12424: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/yellow.png! [plugins_warnings #408|http://ci.jenkins-ci.org/job/plugins_warnings/408/] Result = UNSTABLE > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162589#comment-162589 ] dogfood commented on JENKINS-12424: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_pmd #348|http://ci.jenkins-ci.org/job/plugins_pmd/348/] Result = SUCCESS > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9679) NoClassDefFoundError on Base64 when launching an headless slave with -jnlpCredential option
[ https://issues.jenkins-ci.org/browse/JENKINS-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162591#comment-162591 ] Liam Staskawicz commented on JENKINS-9679: -- Would love to see this addressed or elevated in priority - this is a critical component of putting together a master/slave cluster, and has been known for just about a year now. I say this without being able to fix it myself of course :) but this would be a great help to people setting up multi configuration systems. > NoClassDefFoundError on Base64 when launching an headless slave with > -jnlpCredential option > --- > > Key: JENKINS-9679 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9679 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Jenkins 1.411 / MacOS X / JDK 1.6.0_24 > Jenkins 1.412 / Master: Ubuntu 10.04, / Slave: Windows Server 2008 x64, JDK > 1.6.0_20 > Jenkins 1.424.2 / Master: CentOS 5.5, / Slave: Windows Server 2008 R2 x64, > JDK 1.6.0_21 >Reporter: Olivier Mansion > > When launching a headless slave, a NoClassDefFoundError on > org/apache/commons/codec/binary/Base64 is raised when specifying the > -jnlpCredential option: > $ java -jar slave.jar -jnlpUrl -jnlpCredentials : > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/codec/binary/Base64 > at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:221) > at hudson.remoting.Launcher.run(Launcher.java:192) > at hudson.remoting.Launcher.main(Launcher.java:168) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.codec.binary.Base64 > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > ... 3 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13717) Mercurial URL hook for triggering polling doesn't work with user/pass set in the repository URL
Gonzalo Sainz-Trapaga created JENKINS-13717: --- Summary: Mercurial URL hook for triggering polling doesn't work with user/pass set in the repository URL Key: JENKINS-13717 URL: https://issues.jenkins-ci.org/browse/JENKINS-13717 Project: Jenkins Issue Type: Bug Components: mercurial Affects Versions: current Reporter: Gonzalo Sainz-Trapaga Assignee: Kohsuke Kawaguchi This is basically the equivalent of JENKINS-13410 for the Mercurial plugin. If I set the repo URL to something on the lines of https://user:pass@url/repo, if I use the notifyCommit hook provided since 1.38 I get a "No mercurial jobs found" message from the server. Command line is: $ curl https://jenkins/mercurial/notifyCommit?url=https://user:pass@url/repo (copy pasted from the actual URL in the job setup) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
