[JIRA] (JENKINS-12666) Subversion fails first revision check
[
https://issues.jenkins-ci.org/browse/JENKINS-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158760#comment-158760
]
lfischer commented on JENKINS-12666:
This seems to be related to my Subversion configuration. I need to prevent
anonymous read access.
Jenkins / Subversion plugin tries to read the Subversion revision details
without authentification and the Subversion server rejects this.
Should Jenkins be forced to use authentification, if there are known
credentials?
> Subversion fails first revision check
> -
>
> Key: JENKINS-12666
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12666
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
>Affects Versions: current
> Environment: SuseEnterprise Linux
> JDK 1.6
>Reporter: lfischer
>
> After committing a change into a Subversion repository, Jenkins jobs fail on
> the first Subversion revision check (see log below).
> Restarting the same job without any other Subversion commit, the revision
> check has no error and the job runs fine.
> After the next commit, the same error occurs.
> The Subversion server (1.6) runns on a different machine. Authentication is
> activated. Jenkins knows the credentials of the repo.
> I tested Subversion plugin 1.34, 1.35 and 1.37: always the same error.
> Log:
> {code}
> Started by user Fischer, Lars
> Building on master in workspace
> /data/hudson_home/jobs/test.pt.prototype-parent/workspace
> Updating svn://server/test/prototype/parent
> U pom.xml
> At revision 8512
> hudson.util.IOException2: revision check failed on
> svn://server/test/prototype/parent
>at
> hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:170)
>at
> hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:112)
>at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:555)
>at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:702)
>at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
>at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:576)
>at
> hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:465)
>at hudson.model.Run.run(Run.java:1409)
>at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
>at hudson.model.ResourceController.execute(ResourceController.java:88)
>at hudson.model.Executor.run(Executor.java:238)
> Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn:
> Item is not readable
>at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62)
>at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
>at
> org.tmatesoft.svn.core.internal.io.svn.SVNReader.handleFailureStatus(SVNReader.java:269)
>at
> org.tmatesoft.svn.core.internal.io.svn.SVNReader.parse(SVNReader.java:248)
>at
> org.tmatesoft.svn.core.internal.io.svn.SVNConnection.read(SVNConnection.java:260)
>at
> org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.read(SVNRepositoryImpl.java:1280)
>at
> org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.logImpl(SVNRepositoryImpl.java:835)
>at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:1034)
>at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:1027)
>at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:894)
>at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:826)
>at
> hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:158)
>... 10 more
> Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: Item is not readable
>at
> org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
>at
> org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146)
>at
> org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89)
>at
> org.tmatesoft.svn.core.internal.io.svn.SVNReader.getErrorMessage(SVNReader.java:283)
>at
> org.tmatesoft.svn.core.internal.io.svn.SVNReader.handleFailureStatus(SVNReader.java:261)
>... 19 more
> Retrying after 10 seconds
> {code}
--
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-12678) "Build other projects" as a promotion action seems to use legacy build invocation
R. Tyler Croy created JENKINS-12678: --- Summary: "Build other projects" as a promotion action seems to use legacy build invocation Key: JENKINS-12678 URL: https://issues.jenkins-ci.org/browse/JENKINS-12678 Project: Jenkins Issue Type: Bug Components: promoted-builds Reporter: R. Tyler Croy When invoking another project as a promotion action (let's call it JobB), then the "cause" of JobB's builds is listed as being invoked by some "legacy" action and as such Jenkins has trouble determining the cause. This causes a subsequent failure from the Copy Artifacts plugin step in JobB which tries to copy "from the upstream job" :( -- 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-11041) CI game fails with NPE
[
https://issues.jenkins-ci.org/browse/JENKINS-11041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158761#comment-158761
]
Junqueira Raphael commented on JENKINS-11041:
-
Same Here :
- Jenkins ver. 1.450
- Jenkins Continuous Integration game 1.18
ERROR: Publisher hudson.plugins.cigame.GamePublisher aborted due to exception
java.lang.NullPointerException
at hudson.plugins.cigame.model.ScoreCard.record(ScoreCard.java:44)
at hudson.plugins.cigame.model.ScoreCard.record(ScoreCard.java:111)
at hudson.plugins.cigame.GamePublisher.perform(GamePublisher.java:60)
at hudson.plugins.cigame.GamePublisher.perform(GamePublisher.java:45)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:653)
at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171)
at hudson.model.Run.run(Run.java:1453)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
> CI game fails with NPE
> --
>
> Key: JENKINS-11041
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11041
> Project: Jenkins
> Issue Type: Bug
> Components: ci-game
>Reporter: voorth
>Assignee: redsolo
>
> after updating the plugin, all builds fail:
> {code}
> ERROR: Publisher hudson.plugins.cigame.GamePublisher aborted due to exception
> java.lang.NullPointerException
> at hudson.plugins.cigame.model.ScoreCard.record(ScoreCard.java:44)
> at hudson.plugins.cigame.model.ScoreCard.record(ScoreCard.java:111)
> at hudson.plugins.cigame.GamePublisher.perform(GamePublisher.java:60)
> at hudson.plugins.cigame.GamePublisher.perform(GamePublisher.java:45)
> at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
> at
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:693)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:668)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:646)
> at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171)
> at hudson.model.Run.run(Run.java:1420)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:230)
> {code}
--
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-12679) Matrix-Build Console Links to Hudson instead of Jenkins
Daniel Schaarschmidt created JENKINS-12679: -- Summary: Matrix-Build Console Links to Hudson instead of Jenkins Key: JENKINS-12679 URL: https://issues.jenkins-ci.org/browse/JENKINS-12679 Project: Jenkins Issue Type: Bug Components: matrix Affects Versions: current Reporter: Daniel Schaarschmidt I have configured a Matrix-Build using multiple slave nodes. The parent console output contains the following: Löse OS11.4-64 aus OS11.4-64 beendet mit Ergebnis SUCCESS Löse OS11.1-32 aus OS11.1-32 beendet mit Ergebnis SUCCESS Finished: SUCCESS The Labels OSS11.4-64 and OS11.1-32 are links, but instead of pointing to http:///jenkins/job//label=OS11.4-64/ they link to http:///hudson/job//label=OS11.4-64/ Even better would be a direct link to the corresponding console log:http:///jenkins/job//6/label=OS11.1-32/console -- 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-12680) onOffline in ComputerListener not getting called when node is taken offline
Jens Christensen created JENKINS-12680: -- Summary: onOffline in ComputerListener not getting called when node is taken offline Key: JENKINS-12680 URL: https://issues.jenkins-ci.org/browse/JENKINS-12680 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: OS: All Reporter: Jens Christensen In ComputerListener, onOffline is only called if a node is taken down with the disconnect link in jenkins, any other cause for a node to go offline, makes the call postponed until the master is taken down. -- 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-11041) CI game fails with NPE
[
https://issues.jenkins-ci.org/browse/JENKINS-11041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158762#comment-158762
]
Junqueira Raphael commented on JENKINS-11041:
-
Note : removing old configuration seems to fix the problem
> CI game fails with NPE
> --
>
> Key: JENKINS-11041
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11041
> Project: Jenkins
> Issue Type: Bug
> Components: ci-game
>Reporter: voorth
>Assignee: redsolo
>
> after updating the plugin, all builds fail:
> {code}
> ERROR: Publisher hudson.plugins.cigame.GamePublisher aborted due to exception
> java.lang.NullPointerException
> at hudson.plugins.cigame.model.ScoreCard.record(ScoreCard.java:44)
> at hudson.plugins.cigame.model.ScoreCard.record(ScoreCard.java:111)
> at hudson.plugins.cigame.GamePublisher.perform(GamePublisher.java:60)
> at hudson.plugins.cigame.GamePublisher.perform(GamePublisher.java:45)
> at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
> at
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:693)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:668)
> at
> hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:646)
> at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171)
> at hudson.model.Run.run(Run.java:1420)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:230)
> {code}
--
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-12006) Branch specifier does not replace matrix build variables
[
https://issues.jenkins-ci.org/browse/JENKINS-12006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158763#comment-158763
]
Daniel Schaarschmidt commented on JENKINS-12006:
CVS: Does not work either. Would be nice to have this feature.
> Branch specifier does not replace matrix build variables
>
>
> Key: JENKINS-12006
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12006
> Project: Jenkins
> Issue Type: Bug
> Components: git
>Reporter: Christian Weiske
>Assignee: abayer
>
> Using a matrix build variable in the "Branch Specifier" setting does not work.
> Example:
> - Job is a matrix build job
> - Configuration matrix has one axis, name "CONFBRANCH". One of the values is
> "master'.
> - Git "Branch Specifier (blank for default)" is set to "origin/$CONFBRANCH"
> - When building, the branch is NOT {{origin/master}} as I'd expect but
> {{origin/$CONFBRANCH}} which obviously does not 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-5413) SCM polling on slaves getting hung
[ https://issues.jenkins-ci.org/browse/JENKINS-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158764#comment-158764 ] Franck Gilliers commented on JENKINS-5413: -- Hello, I experience the same issue. If it can help, i describe my configuration: master : linux - jenkins 1.448 slaves : windows XP and seven via a service - msysgit 1.7.4 plugin git : 1.1.15 projects ~ 100 I trigger a build via the push notification as describe in git plugin 1.1.14. But, as it does not always trigger the build (i do not know why), i keep a SCM polling every two hours. To avoid the hanging, every night I restart the server and reboot slaves. During daytime, i have to kill the children git processes to free the slave > SCM polling on slaves getting hung > -- > > Key: JENKINS-5413 > URL: https://issues.jenkins-ci.org/browse/JENKINS-5413 > Project: Jenkins > Issue Type: Bug > Components: master-slave >Affects Versions: current >Reporter: Dean Yu > Attachments: hung_scm_pollers_02.PNG, threads.vetted.txt, > thread_dump_02.txt > > > This is to track the problem originally reported here: > http://n4.nabble.com/Polling-hung-td1310838.html#a1310838 > The referenced thread is relocated to > http://jenkins.361315.n4.nabble.com/Polling-hung-td1310838.html > What the problem boils down to is that many remote operations are performed > synchronously causing the channel object to be locked while a response > returns. In situations where a lengthy remote operations is using the > channel, SCM polling can be blocked waiting for the monitor on the channel to > be released. In extreme situations, all the polling threads can wind up > waiting on object monitors for the channel objects, preventing further > processing of polling tasks. > Furthermore, if the slave dies, the locked channel object still exists in the > master JVM. If no IOException is thrown to indicate the termination of the > connection to the pipe, the channel can never be closed because > Channel.close() itself is a sychronized operation. -- 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-12628) Executable file permission not set anymore
[ https://issues.jenkins-ci.org/browse/JENKINS-12628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158765#comment-158765 ] Alex Lehmann commented on JENKINS-12628: I have to admit that I wasn't aware of the file execute property in java 6, that should be possible to implement (is an issue for the library though I guess). Jenkins is still supporting Java 5, though I think. > Executable file permission not set anymore > -- > > Key: JENKINS-12628 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12628 > Project: Jenkins > Issue Type: Bug > Components: cvs > Environment: CentOS release 5.7 (affected system, Slave), Windows > Server 2003 (Master) >Reporter: Marco Borm > Fix For: current > > > Updating the cvs plugin from 1.6 to 2.0 breaks all our linux builds, due the > fact that our compile scripts don't have executable permission bit set > anymore. The bit is correctly set on the affected files on cvs server side. > cvs plugin 1.6: > -rwxrwx--- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release > cvs plugin 2.0: > -rw-rw-r-- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release -- 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-12628) Executable file permission not set anymore
[ https://issues.jenkins-ci.org/browse/JENKINS-12628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158766#comment-158766 ] Marco Borm commented on JENKINS-12628: -- I'm a C++, not a Java developer: Maybe a call to chmod could a solution if the java cvslib runs on Java 5? > Executable file permission not set anymore > -- > > Key: JENKINS-12628 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12628 > Project: Jenkins > Issue Type: Bug > Components: cvs > Environment: CentOS release 5.7 (affected system, Slave), Windows > Server 2003 (Master) >Reporter: Marco Borm > Fix For: current > > > Updating the cvs plugin from 1.6 to 2.0 breaks all our linux builds, due the > fact that our compile scripts don't have executable permission bit set > anymore. The bit is correctly set on the affected files on cvs server side. > cvs plugin 1.6: > -rwxrwx--- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release > cvs plugin 2.0: > -rw-rw-r-- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release -- 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-11029) FATAL: Unable to produce a script file
[ https://issues.jenkins-ci.org/browse/JENKINS-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158767#comment-158767 ] Mikhail Samolinov commented on JENKINS-11029: - The issue can be also seen with Jenkins 1.450 running on Mac OS X 10.6.8. A quick workaround is to reboot the server. > FATAL: Unable to produce a script file > -- > > Key: JENKINS-11029 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11029 > Project: Jenkins > Issue Type: Bug > Components: maven2 > Environment: OS : RHEL 5.5 32 bit > Jenkins : 1.429 > Java Used : Sunjdk >Reporter: Pushkaraj P > > We get this failure in our build ( This is just after checkout , so not sure > if checkout and this is related > FATAL: Unable to produce a script file > hudson.util.IOException2: Failed to create a temp file on > /home/hudson/jobs/VMCTrunk/workspace > at hudson.FilePath.createTextTempFile(FilePath.java:966) > at > hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:104) > at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) > 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:693) > 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:459) > 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: hudson.util.IOException2: Failed to create a temporary directory > in /tmp > at hudson.FilePath$12.invoke(FilePath.java:955) > at hudson.FilePath$12.invoke(FilePath.java:944) > at hudson.FilePath.act(FilePath.java:758) > at hudson.FilePath.act(FilePath.java:740) > at hudson.FilePath.createTextTempFile(FilePath.java:944) > ... 12 more > Caused by: java.io.IOException: No such file or directory > at java.io.UnixFileSystem.createFileExclusively(Native Method) > at java.io.File.checkAndCreate(File.java:1704) > at java.io.File.createTempFile(File.java:1792) > at hudson.FilePath$12.invoke(FilePath.java:953) > ... 16 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-11029) FATAL: Unable to produce a script file
[ https://issues.jenkins-ci.org/browse/JENKINS-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Samolinov updated JENKINS-11029: Environment: Env #1 OS : RHEL 5.5 32 bit Jenkins : 1.429 Java Used : Sunjdk Env #2 OS: Mac OS X 10.6.8 Jenkins: 1.450 Java: 1.6.0_29 was: OS : RHEL 5.5 32 bit Jenkins : 1.429 Java Used : Sunjdk > FATAL: Unable to produce a script file > -- > > Key: JENKINS-11029 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11029 > Project: Jenkins > Issue Type: Bug > Components: maven2 > Environment: Env #1 > OS : RHEL 5.5 32 bit > Jenkins : 1.429 > Java Used : Sunjdk > Env #2 > OS: Mac OS X 10.6.8 > Jenkins: 1.450 > Java: 1.6.0_29 >Reporter: Pushkaraj P > > We get this failure in our build ( This is just after checkout , so not sure > if checkout and this is related > FATAL: Unable to produce a script file > hudson.util.IOException2: Failed to create a temp file on > /home/hudson/jobs/VMCTrunk/workspace > at hudson.FilePath.createTextTempFile(FilePath.java:966) > at > hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:104) > at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) > 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:693) > 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:459) > 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: hudson.util.IOException2: Failed to create a temporary directory > in /tmp > at hudson.FilePath$12.invoke(FilePath.java:955) > at hudson.FilePath$12.invoke(FilePath.java:944) > at hudson.FilePath.act(FilePath.java:758) > at hudson.FilePath.act(FilePath.java:740) > at hudson.FilePath.createTextTempFile(FilePath.java:944) > ... 12 more > Caused by: java.io.IOException: No such file or directory > at java.io.UnixFileSystem.createFileExclusively(Native Method) > at java.io.File.checkAndCreate(File.java:1704) > at java.io.File.createTempFile(File.java:1792) > at hudson.FilePath$12.invoke(FilePath.java:953) > ... 16 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-5413) SCM polling on slaves getting hung
[ https://issues.jenkins-ci.org/browse/JENKINS-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158768#comment-158768 ] Christian Wolfgang commented on JENKINS-5413: - I see two branches of this issue: 1) The fact that slaves gets hung(or threads winds up waiting for lengthy polling) and how the master Jenkins instance should handle this, and 2) How to prevent slaves from getting hung. The initial issue suggests 1), but some of the replies suggests 2). I guess both are valid issues. Should they be treated as one or should this issue be split up in two? > SCM polling on slaves getting hung > -- > > Key: JENKINS-5413 > URL: https://issues.jenkins-ci.org/browse/JENKINS-5413 > Project: Jenkins > Issue Type: Bug > Components: master-slave >Affects Versions: current >Reporter: Dean Yu > Attachments: hung_scm_pollers_02.PNG, threads.vetted.txt, > thread_dump_02.txt > > > This is to track the problem originally reported here: > http://n4.nabble.com/Polling-hung-td1310838.html#a1310838 > The referenced thread is relocated to > http://jenkins.361315.n4.nabble.com/Polling-hung-td1310838.html > What the problem boils down to is that many remote operations are performed > synchronously causing the channel object to be locked while a response > returns. In situations where a lengthy remote operations is using the > channel, SCM polling can be blocked waiting for the monitor on the channel to > be released. In extreme situations, all the polling threads can wind up > waiting on object monitors for the channel objects, preventing further > processing of polling tasks. > Furthermore, if the slave dies, the locked channel object still exists in the > master JVM. If no IOException is thrown to indicate the termination of the > connection to the pipe, the channel can never be closed because > Channel.close() itself is a sychronized operation. -- 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-12660) Fail to start the windows service when trying to launch slave node
[
https://issues.jenkins-ci.org/browse/JENKINS-12660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158769#comment-158769
]
Benny Chew commented on JENKINS-12660:
--
Have the same issue as well as stated above, master is 1.450, slave a Windows
Server 2008 R2 x64.
> Fail to start the windows service when trying to launch slave node
> --
>
> Key: JENKINS-12660
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12660
> Project: Jenkins
> Issue Type: Bug
> Components: slave-setup
>Affects Versions: current
> Environment: Master : Redhat 5
> Slave Node : Win7 x64
>Reporter: Rico ZHANG
>Assignee: Kohsuke Kawaguchi
>
> We used to be able to launch the slave node successfully, but it did not work
> since we upgraded the jenkins to latest version (1.449)
> It doesn't dump any exception to the console, but I captured the output:
> {noformat}
> Connecting to 192.168.160.62
> Checking if Java exists
> java full version "1.7.0-b147"
> Installing the Jenkins slave service
> Copying jenkins-slave.exe
> Copying slave.jar
> Copying jenkins-slave.xml
> Registering the service
> ERROR: Failed to create a service: Status Invalid Service Account
> ...
> {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-11309) Email notifications are sent on build failures regardless of options
[ https://issues.jenkins-ci.org/browse/JENKINS-11309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158770#comment-158770 ] Slide-O-Mix commented on JENKINS-11309: --- Is this still an issue for you? Can you please give more information on what you are seeing? > Email notifications are sent on build failures regardless of options > > > Key: JENKINS-11309 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11309 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Jenkins 1.433 >Reporter: Uri Moszkowicz >Assignee: Slide-O-Mix > > Email notifications are sent on every build failure by default for Jenkins. > As discussed on the mailing list, if email notifications are only desired on > state changes than one should install the email-ext plugin and for each > project add still-failing triggers which all notifications unchecked. > Unfortunately, the proposed solution does not work and the emails are still > sent. Removal of $PROJECT_DEFAULT_RECIPIENTS and $DEFAULT_RECIPIENTS does not > fix the issue either. The only solution that seems to fix the problem is to > disable notifications altogether, an undesirable solution. -- 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-11731) The email-ext component (2.15) does not use the "Default user e-mail suffix"
[ https://issues.jenkins-ci.org/browse/JENKINS-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slide-O-Mix updated JENKINS-11731: -- Summary: The email-ext component (2.15) does not use the "Default user e-mail suffix" (was: The email-ext component (2.15) does not use the "Default user e-mail suffix" if a script is used in the recipients field) I tried this without using a script and it doesn't work either, the plugin need to get the default suffix and add it to all addresses that don't have it. > The email-ext component (2.15) does not use the "Default user e-mail suffix" > > > Key: JENKINS-11731 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11731 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Linux + Apache Tomcat 6.0.26 >Reporter: Paolo Di Tommaso >Assignee: Slide-O-Mix >Priority: Minor > Fix For: current > > > In email-ext component (version 2.15) using a script as value for the field > "Global Recipient List", if the script returns a list of recipients that does > not include the host domain name in the addresses, the component will NOT use > the value defined by "Default user e-mail suffix" in the Jenkins config. The > mail sending will fail. -- 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-12663) Mantis plugin does not detect change.
[ https://issues.jenkins-ci.org/browse/JENKINS-12663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158772#comment-158772 ] sogabe commented on JENKINS-12663: -- If you commited with "Fix issue #0010038", then you have to set issue pattern to "issue %ID%". > Mantis plugin does not detect change. > - > > Key: JENKINS-12663 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12663 > Project: Jenkins > Issue Type: Bug > Components: mantis >Reporter: Jan Goyvaerts >Assignee: sogabe > Labels: plugin > > I've configured Jenkins according to > https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin. But i can't have > the tickets updated. > I'm getting this in the console output: [MANTIS] No issues have been found in > the changelog. > For the very same build I have these changes: "Fix issue #0010038." > The Mantis configuration is set to "[ISSUE %ID%]". As indicated in the > plugin's tutorial. > Is this a known issue ? -- 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-12663) Mantis plugin does not detect change.
[ https://issues.jenkins-ci.org/browse/JENKINS-12663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158773#comment-158773 ] Jan Goyvaerts commented on JENKINS-12663: - You mean it's case sensitive ? Because according to the tutorial [ISSUE %ID%] is a match for "fix issue #410". > Mantis plugin does not detect change. > - > > Key: JENKINS-12663 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12663 > Project: Jenkins > Issue Type: Bug > Components: mantis >Reporter: Jan Goyvaerts >Assignee: sogabe > Labels: plugin > > I've configured Jenkins according to > https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin. But i can't have > the tickets updated. > I'm getting this in the console output: [MANTIS] No issues have been found in > the changelog. > For the very same build I have these changes: "Fix issue #0010038." > The Mantis configuration is set to "[ISSUE %ID%]". As indicated in the > plugin's tutorial. > Is this a known issue ? -- 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-3788) "No artifacts are recorded. Is this a Maven project?" only for parallel builds
[ https://issues.jenkins-ci.org/browse/JENKINS-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158774#comment-158774 ] kutzi commented on JENKINS-3788: AFAIK "Build modules in parallel" is considered deprecated now - though it's unfortunately not marked as such. If you want to build modules in parallel, I'd suggest Maven3's -T option. That one should work fine. > "No artifacts are recorded. Is this a Maven project?" only for parallel builds > -- > > Key: JENKINS-3788 > URL: https://issues.jenkins-ci.org/browse/JENKINS-3788 > Project: Jenkins > Issue Type: Bug > Components: maven2 >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: jparent > > I recently enable deployment to a repo post-build action. The deploying part > works fine but whenever I activate parallel builds things go wrong. The top > level --aka parent -- pom.xml obviously has no artifact to deploy and so the > build is marked as failed pretty quickly. That's a problem :( Disable parallel > builds and it works! > > Note that despite the build being marked a failed Hudson still launches the > parallel compilation of the modules -- 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-12463) Selenium grid v2 could have different configuration per slave
[ https://issues.jenkins-ci.org/browse/JENKINS-12463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158775#comment-158775 ] Richard Lavoie commented on JENKINS-12463: -- Thanks for the feedback. Here is some precision about how these needs. Since I don't want to clutter the configuration UI, some configurations will only be available through the FileConfiguration, I'm talking about d and e here. This is some pretty advanced config which I doubt will be frequently used in jenkins. A, B and C are going to be taken care of (b is done, a was not in my mind but easy to do, and e only needs to specify the path for chromedriver which is easy as well) F is behing handled by another issue, see https://issues.jenkins-ci.org/browse/JENKINS-12675 If you want to check the code I've done so far, you can take it from : https://github.com/darkrift/selenium-plugin I'm fairly new to jenkins dev as well, started doing those changes 2 weeks ago but it's rather easy once you know the available parts in jenkins. If you have anything else you want, please submit them. Richard > Selenium grid v2 could have different configuration per slave > - > > Key: JENKINS-12463 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12463 > Project: Jenkins > Issue Type: Improvement > Components: master-slave, selenium >Reporter: Richard Lavoie >Assignee: Kohsuke Kawaguchi > > When running slaves with the selenium grid v2 plugin, each slave could have > different configuration (some not supporting IE on linux, or not chrome). The > suggestion here is to be able to configure the grid v2 configuration per > slave. Not only on the master. -- 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-12463) Selenium grid v2 could have different configuration per slave
[ https://issues.jenkins-ci.org/browse/JENKINS-12463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158776#comment-158776 ] Richard Lavoie commented on JENKINS-12463: -- Can you just explain the goal of D ? Since the hub is running in jenkins directly, I don't see how this could be useful for one to specify it's servlets. Thinking about it, I even doubt it will work to add the custom jar to allow that just like you don't have the flexibility to specify your own CapabilityMatcher because it's jenkins that handles that ... Maybe that needs to be thought about, but I don't see the use rather than using an independant grid for more complex configurations/specifications. What's your thoughts about it ? Thanks Richard > Selenium grid v2 could have different configuration per slave > - > > Key: JENKINS-12463 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12463 > Project: Jenkins > Issue Type: Improvement > Components: master-slave, selenium >Reporter: Richard Lavoie >Assignee: Kohsuke Kawaguchi > > When running slaves with the selenium grid v2 plugin, each slave could have > different configuration (some not supporting IE on linux, or not chrome). The > suggestion here is to be able to configure the grid v2 configuration per > slave. Not only on the master. -- 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-12524) Compliance with Multiple SCMs Plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sogabe resolved JENKINS-12524. -- Resolution: Fixed merged. > Compliance with Multiple SCMs Plugin > > > Key: JENKINS-12524 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12524 > Project: Jenkins > Issue Type: Improvement > Components: github >Reporter: jcarsique > > It would be nice to make the GitHub hook triggering work when using Multiple > SCMs Plugin for making one job retrieve multiple GitHub repositories. -- 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-12681) lib-crypto-util current fails it test suite due to an expires certificate
javacruft created JENKINS-12681: --- Summary: lib-crypto-util current fails it test suite due to an expires certificate Key: JENKINS-12681 URL: https://issues.jenkins-ci.org/browse/JENKINS-12681 Project: Jenkins Issue Type: Bug Components: core Reporter: javacruft Priority: Minor I'm unable to build the source code (and test it) at https://github.com/jenkinsci/lib-crypto-util. One of the certificates used for testing has expired (site.crt): Certificate: Data: Version: 3 (0x2) Serial Number: 37:15:9a:3c:c3:e2:eb:27:e7:f2:2a:67:1b:91:73:f3 Signature Algorithm: sha1WithRSAEncryption Issuer: O=Sun Microsystems Inc, OU=VeriSign Trust Network, OU=Class 3 MPKI Secure Server CA, CN=Sun Microsystems Inc SSL CA Validity Not Before: Jul 13 00:00:00 2009 GMT Not After : Sep 11 23:59:59 2011 GMT Subject: C=us, ST=california, L=santa clara, O=Sun Microsystems Inc, OU=wpe, OU=Class B, CN=identity.sun.com Test failure: --- T E S T S --- Running org.jvnet.hudson.crypto.PKIXTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.615 sec <<< FAILURE! Results : Tests in error: testPathValidation(org.jvnet.hudson.crypto.PKIXTest): timestamp check failed Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- 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-12681) lib-crypto-util fails its test suite due to an expired certificate
[ https://issues.jenkins-ci.org/browse/JENKINS-12681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] javacruft updated JENKINS-12681: Summary: lib-crypto-util fails its test suite due to an expired certificate (was: lib-crypto-util current fails it test suite due to an expires certificate) > lib-crypto-util fails its test suite due to an expired certificate > -- > > Key: JENKINS-12681 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12681 > Project: Jenkins > Issue Type: Bug > Components: core >Reporter: javacruft >Priority: Minor > > I'm unable to build the source code (and test it) at > https://github.com/jenkinsci/lib-crypto-util. > One of the certificates used for testing has expired (site.crt): > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 37:15:9a:3c:c3:e2:eb:27:e7:f2:2a:67:1b:91:73:f3 > Signature Algorithm: sha1WithRSAEncryption > Issuer: O=Sun Microsystems Inc, OU=VeriSign Trust Network, OU=Class 3 > MPKI Secure Server CA, CN=Sun Microsystems Inc SSL CA > Validity > Not Before: Jul 13 00:00:00 2009 GMT > Not After : Sep 11 23:59:59 2011 GMT > Subject: C=us, ST=california, L=santa clara, O=Sun Microsystems Inc, > OU=wpe, OU=Class B, CN=identity.sun.com > Test failure: > --- > T E S T S > --- > Running org.jvnet.hudson.crypto.PKIXTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.615 sec <<< > FAILURE! > Results : > Tests in error: > testPathValidation(org.jvnet.hudson.crypto.PKIXTest): timestamp check failed > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- 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-12302) Remote call on CLI channel from [ip] failed
[
https://issues.jenkins-ci.org/browse/JENKINS-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158778#comment-158778
]
Franck Gilliers commented on JENKINS-12302:
---
This bug is still there in Jenkins ver. 1.450
> Remote call on CLI channel from [ip] failed
> ---
>
> Key: JENKINS-12302
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12302
> Project: Jenkins
> Issue Type: Bug
> Components: cli, groovy
>Affects Versions: current
> Environment: Jenkins 1.446, Linux CentOS
>Reporter: Markus Hjerto
>Assignee: vjuranek
>
> I've had a KillStuckPolling.groovy job running for about 6 months without
> problems, but on January 4th it stopped working with the below stack trace.
> This matches with the release of Jenkins 1.446, which is currently installed.
> I have tried to restart the server without any effect.
> {noformat}
> Killing all stuck SCM polls using ~/bin/KillStuckPolling.groovy
> log4j:WARN No appenders could be found for logger
> (org.apache.commons.beanutils.converters.BooleanConverter).
> log4j:WARN Please initialize the log4j system properly.
> java.io.IOException: Remote call on CLI channel from /[ip] failed
> at hudson.remoting.Channel.call(Channel.java:690)
> at hudson.cli.GroovyCommand.loadScript(GroovyCommand.java:106)
> at hudson.cli.GroovyCommand.run(GroovyCommand.java:93)
> at hudson.cli.CLICommand.main(CLICommand.java:205)
> at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
> at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255)
> at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215)
> 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 java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> 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 java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ExceptionInInitializerError
> at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
> at java.io.ObjectStreamClass.computeDefaultSUID(Unknown Source)
> at java.io.ObjectStreamClass.access$100(Unknown Source)
> at java.io.ObjectStreamClass$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.io.ObjectStreamClass.getSerialVersionUID(Unknown Source)
> at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
> at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
> at java.io.ObjectInputStream.readClassDesc(Unknown Source)
> at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
> at java.io.ObjectInputStream.readObject0(Unknown Source)
> at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
> at java.io.ObjectInputStream.readSerialData(Unknown Source)
> at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
> at java.io.ObjectInputStream.readObject0(Unknown Source)
> at java.io.ObjectInputStream.readObject(Unknown Source)
> at hudson.remoting.UserRequest.deserialize(UserRequest.java:182)
> at hudson.remoting.UserRequest.perform(UserRequest.java:98)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at hudson.cli.CLICommand.(CLICommand.java:448)
> ... 26 more
> Build step 'Execute shell' marked build as failure
> {noformat}
> The groovy script is as follows:
> {code:title=KillStuckPolling.groovy|borderStyle=solid}
> Thread.getAllStackTraces().keySet().each() {
>item ->
>println "Checking item" + item.getName();
>if (item.getName().contains("SCM polling") &&
> item.getName().contains("waiting for hudson.remoting")) {
> println " Interrupting thread " + item.getId();
> item.interrupt()
>}
> }
> {code}
> And the bash script used to start it is as follows
> {code:title=KillStuckPolling.sh|borderStyle=solid|xml}
> #!/bin/bash -e
> echo "## Kills stuck polling jobs on Jenkins
[JIRA] (JENKINS-12672) Jobs take a long time to complete - get stuck sending success/failure email
[ https://issues.jenkins-ci.org/browse/JENKINS-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158779#comment-158779 ] Ed Palazzo commented on JENKINS-12672: -- Thanks, Rob. I really appreciate your quick response. Yes, we have lots of projects (something like 300 jobs across 6 branches of code) and lots of builds of those projects. I'll give the snapshot a whirl next time I bring the server down. > Jobs take a long time to complete - get stuck sending success/failure email > --- > > Key: JENKINS-12672 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12672 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: Jenkins 1.450 > Perforce plugin 1.3.7 > Red Hat Enterprise Linux 4.5 >Reporter: Ed Palazzo >Assignee: Rob Petti > > We've noticed that sometimes our jobs get in a state where they're taking a > long time to complete. Investigation reveals that the maven build has > completing successfully, and it's "stuck" trying to send a success email. > Left alone, the build will eventually complete but a 10 minute build may take > several hours to succeed and blocks other jobs since the executors are busy. > Manual monitoring and intervention is usually required to free up the jobs. > Here's an example thread taken from a Jenkins thread dump that shows the > "stuck" job. It appears to be processing the change list to retrieve the > checkin user(s) that checked in code. Why is this taking so long? > The exact stack changes with each thread dump, but it is consistent up to > PerforceChangeLogSet.parse(PerforceChangeLogSet.java:111). > "Executor #2 for master : executing markview-7.0.x_document-server #103" > prio=10 tid=0x48865400 nid=0x5109 runnable [0x49bfa000] >java.lang.Thread.State: RUNNABLE > at java.util.ArrayList.size(ArrayList.java:177) > at org.dom4j.tree.BackedList.(BackedList.java:36) > at > org.dom4j.tree.AbstractBranch.createResultList(AbstractBranch.java:373) > at org.dom4j.tree.AbstractElement.elements(AbstractElement.java:392) > at > org.dom4j.tree.AbstractElement.elementIterator(AbstractElement.java:428) > at > org.jaxen.dom4j.DocumentNavigator.getChildAxisIterator(DocumentNavigator.java:233) > at > org.jaxen.expr.iter.IterableChildAxis.namedAccessIterator(IterableChildAxis.java:98) > at org.jaxen.expr.DefaultNameStep.evaluate(DefaultNameStep.java:180) > at > org.jaxen.expr.DefaultLocationPath.evaluate(DefaultLocationPath.java:140) > at org.jaxen.expr.DefaultXPathExpr.asList(DefaultXPathExpr.java:102) > at org.jaxen.BaseXPath.selectNodesForContext(BaseXPath.java:674) > at org.jaxen.BaseXPath.selectNodes(BaseXPath.java:213) > at org.jaxen.BaseXPath.selectSingleNode(BaseXPath.java:234) > at > org.dom4j.xpath.DefaultXPath.selectSingleNode(DefaultXPath.java:159) > at org.dom4j.tree.AbstractNode.selectSingleNode(AbstractNode.java:185) > at > hudson.plugins.perforce.PerforceChangeLogSet.parse(PerforceChangeLogSet.java:111) > at > hudson.plugins.perforce.PerforceChangeLogParser.parse(PerforceChangeLogParser.java:18) > at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:808) > at hudson.model.AbstractBuild.getChangeSet(AbstractBuild.java:782) > at hudson.model.AbstractBuild.hasParticipant(AbstractBuild.java:356) > at > hudson.model.AbstractProject.hasParticipant(AbstractProject.java:1366) > at hudson.model.User.getProjects(User.java:402) > at > hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:38) > at > hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) > at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) > at > hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:331) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:251) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) > at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.cleanUp(MavenModuleSetBuild.java:1022) > at hudson.model.Run.run(Run.java:1453) > at hudson.maven.MavenModuleSetBuild.run
[JIRA] (JENKINS-12663) Mantis plugin does not detect change.
[ https://issues.jenkins-ci.org/browse/JENKINS-12663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158780#comment-158780 ] Jan Goyvaerts commented on JENKINS-12663: - It doesn't work either. I'm sending screenshots of the configuration. > Mantis plugin does not detect change. > - > > Key: JENKINS-12663 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12663 > Project: Jenkins > Issue Type: Bug > Components: mantis >Reporter: Jan Goyvaerts >Assignee: sogabe > Labels: plugin > > I've configured Jenkins according to > https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin. But i can't have > the tickets updated. > I'm getting this in the console output: [MANTIS] No issues have been found in > the changelog. > For the very same build I have these changes: "Fix issue #0010038." > The Mantis configuration is set to "[ISSUE %ID%]". As indicated in the > plugin's tutorial. > Is this a known issue ? -- 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-12682) Exception configuring Cloud
David Corbin created JENKINS-12682: -- Summary: Exception configuring Cloud Key: JENKINS-12682 URL: https://issues.jenkins-ci.org/browse/JENKINS-12682 Project: Jenkins Issue Type: Bug Components: labmanager Affects Versions: current Environment: Windows 2003, Tomcat, Lab Manager: 4.0.2.1269 Reporter: David Corbin Assignee: Tom Rini When I attempt to configure my LabManager cloud and "Test Connection", I get the following exception: Test Connection Testing... ERROR HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: java.lang.RuntimeException: org.apache.axiom.om.impl.exception.OMBuilderException: detail unsupported element in SOAPFault element org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:605) org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234) org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) org.kohsuke.stapler.Stapler.service(Stapler.java:159) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:52) hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) root cause java.lang.RuntimeException: org.apache.axiom.om.impl.exception.OMBuilderException: detail unsupported element in SOAPFault element hudson.plugins.labmanager.LabManager$DescriptorImpl.doTestConnection(LabManager.java:321) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282) org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149) org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88) org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:104) org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234) org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) org.kohsuke.stapler.Stapler.invoke(Stapler.java:648) org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) org.kohsuke.stapler.Stapler.service(Stapler.java:159) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:52) hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) root cause org.apache.axiom.om.impl.exception.OMBuilderException: detail unsupported element in SOAPFault element org.apache.axiom.soap.impl.builder.SOAP12BuilderHelper.handleEvent(SOAP12BuilderHelper.java:175) org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.constructNode(StAXSOAPModelBuilder.java:428) org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.createOMElement(StAXSOAPModelBuilder.java:265)
[JIRA] (JENKINS-12663) Mantis plugin does not detect change.
[ https://issues.jenkins-ci.org/browse/JENKINS-12663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Goyvaerts updated JENKINS-12663: Attachment: mantis_project_config.png Mantis configuration of the project. > Mantis plugin does not detect change. > - > > Key: JENKINS-12663 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12663 > Project: Jenkins > Issue Type: Bug > Components: mantis >Reporter: Jan Goyvaerts >Assignee: sogabe > Labels: plugin > Attachments: mantis_project_config.png, project_changes.png > > > I've configured Jenkins according to > https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin. But i can't have > the tickets updated. > I'm getting this in the console output: [MANTIS] No issues have been found in > the changelog. > For the very same build I have these changes: "Fix issue #0010038." > The Mantis configuration is set to "[ISSUE %ID%]". As indicated in the > plugin's tutorial. > Is this a known issue ? -- 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-12663) Mantis plugin does not detect change.
[ https://issues.jenkins-ci.org/browse/JENKINS-12663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Goyvaerts updated JENKINS-12663: Attachment: project_changes.png Listed changes of the build. The change that should have been picked up is at 2. > Mantis plugin does not detect change. > - > > Key: JENKINS-12663 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12663 > Project: Jenkins > Issue Type: Bug > Components: mantis >Reporter: Jan Goyvaerts >Assignee: sogabe > Labels: plugin > Attachments: mantis_project_config.png, project_changes.png > > > I've configured Jenkins according to > https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin. But i can't have > the tickets updated. > I'm getting this in the console output: [MANTIS] No issues have been found in > the changelog. > For the very same build I have these changes: "Fix issue #0010038." > The Mantis configuration is set to "[ISSUE %ID%]". As indicated in the > plugin's tutorial. > Is this a known issue ? -- 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-12663) Mantis plugin does not detect change.
[ https://issues.jenkins-ci.org/browse/JENKINS-12663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Goyvaerts updated JENKINS-12663: Attachment: build_console_output.png Output of the console at the end of the build stating Mantis didn't pick something up. > Mantis plugin does not detect change. > - > > Key: JENKINS-12663 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12663 > Project: Jenkins > Issue Type: Bug > Components: mantis >Reporter: Jan Goyvaerts >Assignee: sogabe > Labels: plugin > Attachments: build_console_output.png, mantis_project_config.png, > project_changes.png > > > I've configured Jenkins according to > https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin. But i can't have > the tickets updated. > I'm getting this in the console output: [MANTIS] No issues have been found in > the changelog. > For the very same build I have these changes: "Fix issue #0010038." > The Mantis configuration is set to "[ISSUE %ID%]". As indicated in the > plugin's tutorial. > Is this a known issue ? -- 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-12663) Mantis plugin does not detect change.
[ https://issues.jenkins-ci.org/browse/JENKINS-12663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158784#comment-158784 ] Jan Goyvaerts commented on JENKINS-12663: - Maybe it's a system thing ? JDK 1.7u2 (64bit) Debian 6 (64bit) Jenkins version 1.446 Mantis plugin version 0.21 > Mantis plugin does not detect change. > - > > Key: JENKINS-12663 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12663 > Project: Jenkins > Issue Type: Bug > Components: mantis >Reporter: Jan Goyvaerts >Assignee: sogabe > Labels: plugin > Attachments: build_console_output.png, mantis_project_config.png, > project_changes.png > > > I've configured Jenkins according to > https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin. But i can't have > the tickets updated. > I'm getting this in the console output: [MANTIS] No issues have been found in > the changelog. > For the very same build I have these changes: "Fix issue #0010038." > The Mantis configuration is set to "[ISSUE %ID%]". As indicated in the > plugin's tutorial. > Is this a known issue ? -- 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-12113) Maven - java.io.IOException: error=2, No such file or directory if in SVN configuration parameters used in Local module directory section
[ https://issues.jenkins-ci.org/browse/JENKINS-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158726#comment-158726 ] Oleksandr Popov edited comment on JENKINS-12113 at 2/8/12 3:35 PM: --- Yes! Looks like that fixes the issue... was (Author: pxantom): Yes! Looks like that fixes the issue... I think the similar change needed for Ant. > Maven - java.io.IOException: error=2, No such file or directory if in SVN > configuration parameters used in Local module directory section > - > > Key: JENKINS-12113 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12113 > Project: Jenkins > Issue Type: Bug > Components: core, maven, maven2, parameters, subversion > Environment: Jenkins 1.448 > Subversion Plugin 1.37 > Maven Integration Plugin 1.448 > Ant 1.1 >Reporter: Oleksandr Popov >Assignee: kutzi > Attachments: subversion.hpi, svn_maven_issue_01.PNG, > svn_maven_issue_02.PNG > > > Maven is unable to work if in Subversion configuration parameters are used in > Local module directory section. > As you can see in svn_maven_issue_01.PNG Ive specified predefined variable in > Local module directory section. And when I run it - Maven failed > (svn_maven_issue_02.PNG) with java.io.IOException. -- 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-12267) Failure to load many builds when Jenkins start
[
https://issues.jenkins-ci.org/browse/JENKINS-12267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158785#comment-158785
]
Harald Albers commented on JENKINS-12267:
-
Same setup with identical problem here. Reloading from disk solves the issue
for the current session. Downgrading git plugin to 1.1.15 permanently resolves
the issue.
> Failure to load many builds when Jenkins start
> --
>
> Key: JENKINS-12267
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12267
> Project: Jenkins
> Issue Type: Bug
> Components: core, git
> Environment: Debian Squeeze, amd64, Jenkins installed using the
> Debian package from pkg.jenkins-ci.org.
>Reporter: Jean-Sébastien Pédron
>Assignee: abayer
>
> When Jenkins is restarted, it fails to load most of the builds. The
> {{jenkins.log}} file contains many exceptions like this one:
> {code}hudson.util.IOException2: Unable to read
> /var/lib/jenkins/jobs/bones/builds/2011-12-30_16-42-43/build.xml
> at hudson.XmlFile.unmarshal(XmlFile.java:160)
> at hudson.model.Run.reload(Run.java:283)
> at hudson.model.Run.(Run.java:272)
> at hudson.model.AbstractBuild.(AbstractBuild.java:162)
> at hudson.model.Build.(Build.java:100)
> at hudson.model.FreeStyleBuild.(FreeStyleBuild.java:41)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at hudson.model.AbstractProject.loadBuild(AbstractProject.java:949)
> at hudson.model.AbstractProject$1.create(AbstractProject.java:256)
> at hudson.model.AbstractProject$1.create(AbstractProject.java:254)
> at hudson.model.RunMap.load(RunMap.java:221)
> at hudson.model.AbstractProject.onLoad(AbstractProject.java:254)
> at hudson.model.Project.onLoad(Project.java:88)
> at hudson.model.Items.load(Items.java:115)
> at jenkins.model.Jenkins$14.run(Jenkins.java:2360)
> at
> org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
> at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
> at jenkins.model.Jenkins$5.runTask(Jenkins.java:800)
> at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
> at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
> 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)
> Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot
> deserialize object with new readObject()/writeObject() methods
> Debugging information
> class : hudson.model.FreeStyleBuild
> required-type : org.eclipse.jgit.lib.ObjectId
> path:
> /build/actions/hudson.plugins.git.util.BuildData/buildsByBranchName/entry/hudson.plugins.git.util.Build/revision/sha1
> line number : 18
> ---
> at
> com.thoughtworks.xstream.converters.reflection.SerializableConverter.doUnmarshal(SerializableConverter.java:281)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
> at
> com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
> at
> hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:290)
> at
> hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:233)
> at
> hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:180)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
> at
> com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
> a
[JIRA] (JENKINS-12267) Failure to load many builds when Jenkins start
[
https://issues.jenkins-ci.org/browse/JENKINS-12267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158785#comment-158785
]
Harald Albers edited comment on JENKINS-12267 at 2/8/12 3:51 PM:
-
Same setup with identical problem here. Reloading from disk solves the issue
for the current session. Downgrading git plugin to 1.1.14 permanently resolves
the issue.
was (Author: albers):
Same setup with identical problem here. Reloading from disk solves the
issue for the current session. Downgrading git plugin to 1.1.15 permanently
resolves the issue.
> Failure to load many builds when Jenkins start
> --
>
> Key: JENKINS-12267
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12267
> Project: Jenkins
> Issue Type: Bug
> Components: core, git
> Environment: Debian Squeeze, amd64, Jenkins installed using the
> Debian package from pkg.jenkins-ci.org.
>Reporter: Jean-Sébastien Pédron
>Assignee: abayer
>
> When Jenkins is restarted, it fails to load most of the builds. The
> {{jenkins.log}} file contains many exceptions like this one:
> {code}hudson.util.IOException2: Unable to read
> /var/lib/jenkins/jobs/bones/builds/2011-12-30_16-42-43/build.xml
> at hudson.XmlFile.unmarshal(XmlFile.java:160)
> at hudson.model.Run.reload(Run.java:283)
> at hudson.model.Run.(Run.java:272)
> at hudson.model.AbstractBuild.(AbstractBuild.java:162)
> at hudson.model.Build.(Build.java:100)
> at hudson.model.FreeStyleBuild.(FreeStyleBuild.java:41)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at hudson.model.AbstractProject.loadBuild(AbstractProject.java:949)
> at hudson.model.AbstractProject$1.create(AbstractProject.java:256)
> at hudson.model.AbstractProject$1.create(AbstractProject.java:254)
> at hudson.model.RunMap.load(RunMap.java:221)
> at hudson.model.AbstractProject.onLoad(AbstractProject.java:254)
> at hudson.model.Project.onLoad(Project.java:88)
> at hudson.model.Items.load(Items.java:115)
> at jenkins.model.Jenkins$14.run(Jenkins.java:2360)
> at
> org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
> at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
> at jenkins.model.Jenkins$5.runTask(Jenkins.java:800)
> at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
> at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
> 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)
> Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot
> deserialize object with new readObject()/writeObject() methods
> Debugging information
> class : hudson.model.FreeStyleBuild
> required-type : org.eclipse.jgit.lib.ObjectId
> path:
> /build/actions/hudson.plugins.git.util.BuildData/buildsByBranchName/entry/hudson.plugins.git.util.Build/revision/sha1
> line number : 18
> ---
> at
> com.thoughtworks.xstream.converters.reflection.SerializableConverter.doUnmarshal(SerializableConverter.java:281)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
> at
> com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
> at
> hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:290)
> at
> hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:233)
> at
> hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:180)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
> at
> com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller
[JIRA] (JENKINS-8587) Exception in thread "main" java.lang.NoClassDefFoundError
[
https://issues.jenkins-ci.org/browse/JENKINS-8587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158786#comment-158786
]
Auke van Leeuwen commented on JENKINS-8587:
---
I had the same issue, after much trial and error I found what was causing this:
an extra space between the system properties I was passing.
{noformat}-Darg1=value1 -Darg2=value2{noformat}
fails
{noformat}-Darg1=value1 -Darg2=value2{noformat}
works
> Exception in thread "main" java.lang.NoClassDefFoundError
> -
>
> Key: JENKINS-8587
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8587
> Project: Jenkins
> Issue Type: Bug
> Components: sbt
>Affects Versions: current
>Reporter: uzilan
>Assignee: uzilan
> Fix For: current
>
> Attachments: sbt-hudson-console-log.txt
>
>
> (Copied from https://github.com/hudson/sbt-plugin/issues#issue/1)
> I'm having problems running sbt from Hudson 1.395. Console output says:
> [workspace] $ /usr/lib/jvm/java-6-sun-1.6.0.22/bin/java
> -Dsbt.log.noformat=true -jar
> /home/matt/Downloads/local-root/bin/sbt-launch-0.7.4.jar clean update compile
> test Exception in thread "main" java.lang.NoClassDefFoundError:
> Caused by: java.lang.ClassNotFoundException:
> 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)
> Could not find the main class: . Program will exit.
> Finished: FAILURE
> Running the same sbt command at the shell works fine, however. (Let me know
> if I can provide other relevant info.)
--
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-12655) GIT_BRANCH is incorrect in build steps when branch choosing strategy is set to inverse (but it is correct in build name macro)
[
https://issues.jenkins-ci.org/browse/JENKINS-12655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158787#comment-158787
]
Ruth Morgenstein commented on JENKINS-12655:
note: Step#3 above should say echo ${GIT_BRANCH}
Here is the build log. As you can see, it knows the GIT_BRANCH at one point,
(at the "commencing build" line),
then loses that information in the build script, when it gets echoed.
Started by user rmorgenstein
Building remotely on volt4c in workspace
/var/voltdb/jenkins/workspace/xtest-jenkins
Deleting project workspace... done
Checkout:xtest-jenkins / /var/voltdb/jenkins/workspace/xtest-jenkins -
hudson.remoting.Channel@11c0f73a:volt4c
Using strategy: Inverse
Last Built Revision: Revision d4da8cf9aa3456030142fd56034d87d2f8d22de7
(origin/voltdb-0.6)
Checkout:voltdb / /var/voltdb/jenkins/workspace/xtest-jenkins/voltdb -
hudson.remoting.LocalChannel@630f83c9
Cloning the remote Git repository
Cloning repository origin
Fetching upstream changes from g...@github.com:VoltDB/voltdb.git
Cleaning workspace
Seen branch in repository origin/ElClient
Seen branch in repository origin/HEAD
Seen branch in repository origin/build-tests
...
Seen branch in repository origin/voltcore-integration
Seen branch in repository origin/voltdb-0.6
Seen branch in repository origin/voltdb-0.9
Seen branch in repository origin/voltdb-1.0
...
Commencing build of Revision 5af56f1a105129ae24895c3e6434294cf736ebbe
(origin/voltdb-0.9)
Checking out Revision 5af56f1a105129ae24895c3e6434294cf736ebbe
(origin/voltdb-0.9)
Cleaning workspace
No change to record in branch origin/voltdb-0.9
[xtest-jenkins] $ /bin/sh -xe /tmp/hudson7808160474733240525.sh
+ echo 'GIT_BRANCH = origin/master'
GIT_BRANCH = origin/master
+ echo 'GIT_COMMIT = 5af56f1a105129ae24895c3e6434294cf736ebbe'
GIT_COMMIT = 5af56f1a105129ae24895c3e6434294cf736ebbe
+ echo 'BUILD_TAG = jenkins-xtest-jenkins-8'
BUILD_TAG = jenkins-xtest-jenkins-8
Finished: SUCCESS
> GIT_BRANCH is incorrect in build steps when branch choosing strategy is set
> to inverse (but it is correct in build name macro)
> --
>
> Key: JENKINS-12655
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12655
> Project: Jenkins
> Issue Type: Bug
> Components: git
>Reporter: Ruth Morgenstein
>Assignee: abayer
>
> Context: I'm trying to create a parameterized job chain for our branches.
> Version info:
> Jenkins 1.450
> Git 1.1.15
> build-name-setter 1.3
> parametrized trigger 2.12
> 1) Set the git branch to */master and in advanced, select branching strategy
> = inverse
> 2) Set the build name (using plugin) to #${BUILD_NUMBER}.${GIT_BRANCH}
> 3) In the build, use shell to execute: echo ${BUILD_BRANCH}
> 4) Push a change into a branch in git then manually start the build in Jenkins
> Result:
> The build string is set correctly to the branch used in step#4, but the echo
> in step #3 incorrectly says origin/master. Note, that the wrong GIT_BRANCH is
> also sent in my parameterized trigger.
> The setting for GIT_BRANCH is correct at all times when Default choosing
> strategy is selected.
--
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-11731) The email-ext component (2.15) does not use the "Default user e-mail suffix"
[ https://issues.jenkins-ci.org/browse/JENKINS-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slide-O-Mix resolved JENKINS-11731. --- Resolution: Fixed Fixed in https://github.com/jenkinsci/email-ext-plugin/commit/3789acf5ffab5b55a8d6f1b5a2554a843a53153a > The email-ext component (2.15) does not use the "Default user e-mail suffix" > > > Key: JENKINS-11731 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11731 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: Linux + Apache Tomcat 6.0.26 >Reporter: Paolo Di Tommaso >Assignee: Slide-O-Mix >Priority: Minor > Fix For: current > > > In email-ext component (version 2.15) using a script as value for the field > "Global Recipient List", if the script returns a list of recipients that does > not include the host domain name in the addresses, the component will NOT use > the value defined by "Default user e-mail suffix" in the Jenkins config. The > mail sending will fail. -- 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-12663) Mantis plugin does not detect change.
[ https://issues.jenkins-ci.org/browse/JENKINS-12663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158789#comment-158789 ] sogabe commented on JENKINS-12663: -- try "issue #%ID%". You need "#". > Mantis plugin does not detect change. > - > > Key: JENKINS-12663 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12663 > Project: Jenkins > Issue Type: Bug > Components: mantis >Reporter: Jan Goyvaerts >Assignee: sogabe > Labels: plugin > Attachments: build_console_output.png, mantis_project_config.png, > project_changes.png > > > I've configured Jenkins according to > https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin. But i can't have > the tickets updated. > I'm getting this in the console output: [MANTIS] No issues have been found in > the changelog. > For the very same build I have these changes: "Fix issue #0010038." > The Mantis configuration is set to "[ISSUE %ID%]". As indicated in the > plugin's tutorial. > Is this a known issue ? -- 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-12683) Crowd 2 plugin authenticates, but doesn't allow login
Dan Busha created JENKINS-12683: --- Summary: Crowd 2 plugin authenticates, but doesn't allow login Key: JENKINS-12683 URL: https://issues.jenkins-ci.org/browse/JENKINS-12683 Project: Jenkins Issue Type: Bug Components: crowd2 Affects Versions: current Environment: x64 Windows 7 Reporter: Dan Busha Assignee: Thorsten Heit Priority: Critical I have an installation of Jenkins 1.450 with the Crowd 2 plugin v1.4 installed connecting to a Crowd v2.4.0 server which successfully authenticates users (according to the log). When a user enters their username and password and clicks 'log in' they are returned to the main Jenkins page but are not logged in. -- 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-12684) No way to disable adding Hudson-Build-Number, Hudson-Project, Hudson-Version (and Jenkins analogs) properties to MANIFEST.MF
dave truckenmiller created JENKINS-12684: Summary: No way to disable adding Hudson-Build-Number, Hudson-Project, Hudson-Version (and Jenkins analogs) properties to MANIFEST.MF Key: JENKINS-12684 URL: https://issues.jenkins-ci.org/browse/JENKINS-12684 Project: Jenkins Issue Type: Bug Components: maven2 Affects Versions: current Environment: Linux 64bit, Maven 2.2.1 Reporter: dave truckenmiller When I create a jar file, these properties are added to my MANIFEST.MF file. There seems to be no way to disable adding these. Hudson-Build-Number: 14 Hudson-Project: xx Hudson-Version: 1.424.2 Jenkins-Build-Number: 14 Jenkins-Project: xx Jenkins-Version: 1.424.2 -- 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-12628) Executable file permission not set anymore
[ https://issues.jenkins-ci.org/browse/JENKINS-12628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158790#comment-158790 ] Michael Clarke commented on JENKINS-12628: -- I'd personally rather not have to make system calls (such as chmod) as you're relying on a *nix system which is more of a barrier than relying on having Java 6. I'd prefer to call Java 6 methods and have a fallback if they're not available (Kohsuke wrote a blog post on Jenkins doing this a while back: http://weblogs.java.net/blog/2008/11/14/compiling-jdk6-and-running-jdk5). If we were to implement such a feature then I'd look to having a user warned that files would not be set as executable through a console message or even a warning on the CVS section of the job's config screen. Any thoughts? > Executable file permission not set anymore > -- > > Key: JENKINS-12628 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12628 > Project: Jenkins > Issue Type: Bug > Components: cvs > Environment: CentOS release 5.7 (affected system, Slave), Windows > Server 2003 (Master) >Reporter: Marco Borm > Fix For: current > > > Updating the cvs plugin from 1.6 to 2.0 breaks all our linux builds, due the > fact that our compile scripts don't have executable permission bit set > anymore. The bit is correctly set on the affected files on cvs server side. > cvs plugin 1.6: > -rwxrwx--- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release > cvs plugin 2.0: > -rw-rw-r-- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release -- 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-11466) reenable "ability to let maven decide the versioning"
[ https://issues.jenkins-ci.org/browse/JENKINS-11466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158791#comment-158791 ] Allen Lau commented on JENKINS-11466: - I rely on it for releasing patched binaries. So each module usually have a different version number than the parent/aggregate pom that the jenkins job is triggering. > reenable "ability to let maven decide the versioning" > - > > Key: JENKINS-11466 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11466 > Project: Jenkins > Issue Type: Improvement > Components: m2release >Reporter: domi >Assignee: teilo > > It kind of feels odd to remove a useful feature just because the information > is used for a tooltip in the UI. > please reenable the option "let maven decide the versioning"" removed in 0.8.0 > without this option one is not able to have a workaround to define different > versions for each module. -- 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-12685) There is no way to escape a $ so that it can be used without an exception
Slide-O-Mix created JENKINS-12685: - Summary: There is no way to escape a $ so that it can be used without an exception Key: JENKINS-12685 URL: https://issues.jenkins-ci.org/browse/JENKINS-12685 Project: Jenkins Issue Type: Bug Components: token-macro Affects Versions: current Environment: Token Macro 1.5 Reporter: Slide-O-Mix Assignee: Kohsuke Kawaguchi Priority: Minor With the token macro plugin, if I have something like the following "$4000" in my text, there is an exception for unknown macro thrown. There should be a way to escape the $ so that you can actually use a $ in the text of something that is going to be replaced. -- 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-12628) Executable file permission not set anymore
[
https://issues.jenkins-ci.org/browse/JENKINS-12628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158792#comment-158792
]
Alex Lehmann commented on JENKINS-12628:
chmod isn't necessary on windows anyway, if you have a wrapper the checks if
the target system is unix-like and run chmod or do nothing otherwise
if it is possible to check for java5/java6, this could be used before if
possible, something like this
{code}
if(isUnix) {
if(isJava6) {
File.setExecutable();
} else {
System.execute("chmod ...");
}
} else {
warn("ignoring execute permission for ...");
}
{code}
> Executable file permission not set anymore
> --
>
> Key: JENKINS-12628
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12628
> Project: Jenkins
> Issue Type: Bug
> Components: cvs
> Environment: CentOS release 5.7 (affected system, Slave), Windows
> Server 2003 (Master)
>Reporter: Marco Borm
> Fix For: current
>
>
> Updating the cvs plugin from 1.6 to 2.0 breaks all our linux builds, due the
> fact that our compile scripts don't have executable permission bit set
> anymore. The bit is correctly set on the affected files on cvs server side.
> cvs plugin 1.6:
> -rwxrwx--- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release
> cvs plugin 2.0:
> -rw-rw-r-- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release
--
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-12628) Executable file permission not set anymore
[
https://issues.jenkins-ci.org/browse/JENKINS-12628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158792#comment-158792
]
Alex Lehmann edited comment on JENKINS-12628 at 2/8/12 9:02 PM:
chmod isn't necessary on windows anyway, if you have a wrapper the checks if
the target system is unix-like and run chmod or do nothing otherwise
if it is possible to check for java5/java6, this could be used before if
possible, something like this
{code}
if(isUnix) {
if(isJava6) {
File.setExecutable();
} else {
System.execute("chmod ...");
}
} else {
warn("ignoring execute permission for ...");
}
{code}
if this is properly wrapped in a method, this will not even look bad in the
actual code since that only has to do Wrapper.setExecutable(file);
was (Author: alexlehm):
chmod isn't necessary on windows anyway, if you have a wrapper the checks
if the target system is unix-like and run chmod or do nothing otherwise
if it is possible to check for java5/java6, this could be used before if
possible, something like this
{code}
if(isUnix) {
if(isJava6) {
File.setExecutable();
} else {
System.execute("chmod ...");
}
} else {
warn("ignoring execute permission for ...");
}
{code}
> Executable file permission not set anymore
> --
>
> Key: JENKINS-12628
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12628
> Project: Jenkins
> Issue Type: Bug
> Components: cvs
> Environment: CentOS release 5.7 (affected system, Slave), Windows
> Server 2003 (Master)
>Reporter: Marco Borm
> Fix For: current
>
>
> Updating the cvs plugin from 1.6 to 2.0 breaks all our linux builds, due the
> fact that our compile scripts don't have executable permission bit set
> anymore. The bit is correctly set on the affected files on cvs server side.
> cvs plugin 1.6:
> -rwxrwx--- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release
> cvs plugin 2.0:
> -rw-rw-r-- 1 jenkins jenkins261 15. Mai 2007 compile.linux.so.release
--
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-12686) Predefined parameters on a post-join build are evaluated by a child job rather than parent
Michael Conlon created JENKINS-12686:
Summary: Predefined parameters on a post-join build are evaluated
by a child job rather than parent
Key: JENKINS-12686
URL: https://issues.jenkins-ci.org/browse/JENKINS-12686
Project: Jenkins
Issue Type: Bug
Components: nodelabelparameter, parameterized-trigger
Reporter: Michael Conlon
Assignee: domi
I have a diamond build setup that runs across several machines. The first job
runs on the parent node, then kicks off jobs on multiple child nodes, as well
as on itself...then a join build is done on a grandchild node.
I have a list of predefined parameters, one of which recently failed on me
unexpectedly:
TIMESTAMP=${BUILD_ID}_${NODE_NAME}
I expect these predefined parameters to evaluate on the parent node, where they
are configured (this is how they are evaluated on the pass-off to its
children). However, I just witnessed a grandchild build evaluate these
environment variables during the join action, from a child node (The build_id
and node_names were changed). I'm guessing it was evaluated from the last
job/node to finish, but that wouldn't exactly explain all the other times this
has worked correctly.
--
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-12684) No way to disable adding Hudson-Build-Number, Hudson-Project, Hudson-Version (and Jenkins analogs) properties to MANIFEST.MF
[ https://issues.jenkins-ci.org/browse/JENKINS-12684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dave truckenmiller updated JENKINS-12684: - Description: When I create a jar file, these properties are added to my MANIFEST.MF file. There seems to be no way to disable adding these. Having these in my MANIFEST.MF file causes problems in the QA diff'ing process further on down the road. Is there a work around? Hudson-Build-Number: 14 Hudson-Project: xx Hudson-Version: 1.424.2 Jenkins-Build-Number: 14 Jenkins-Project: xx Jenkins-Version: 1.424.2 was: When I create a jar file, these properties are added to my MANIFEST.MF file. There seems to be no way to disable adding these. Hudson-Build-Number: 14 Hudson-Project: xx Hudson-Version: 1.424.2 Jenkins-Build-Number: 14 Jenkins-Project: xx Jenkins-Version: 1.424.2 > No way to disable adding Hudson-Build-Number, Hudson-Project, Hudson-Version > (and Jenkins analogs) properties to MANIFEST.MF > > > Key: JENKINS-12684 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12684 > Project: Jenkins > Issue Type: Bug > Components: maven2 >Affects Versions: current > Environment: Linux 64bit, Maven 2.2.1 >Reporter: dave truckenmiller > > When I create a jar file, these properties are added to my MANIFEST.MF file. > There seems to be no way to disable adding these. Having these in my > MANIFEST.MF file causes problems in the QA diff'ing process further on down > the road. Is there a work around? > Hudson-Build-Number: 14 > Hudson-Project: xx > Hudson-Version: 1.424.2 > Jenkins-Build-Number: 14 > Jenkins-Project: xx > Jenkins-Version: 1.424.2 -- 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-12686) Predefined parameters on a post-join build are evaluated by a child job rather than parent
[
https://issues.jenkins-ci.org/browse/JENKINS-12686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Conlon updated JENKINS-12686:
-
Description:
I have a diamond build setup that runs across several machines. The first job
runs on the parent node, then kicks off jobs on multiple child nodes, as well
as on itself...then a join build is done on a grandchild node.
I have a list of predefined parameters, one of which recently failed on me
unexpectedly:
TIMESTAMP=${BUILD_ID}_${NODE_NAME}
I expect these predefined parameters to evaluate on the parent node, where they
are configured (this is how they are evaluated on the pass-off to its
children). However, I just witnessed a grandchild build (during the join
action) evaluate these environment variables from a child node (The build_id
and node_names were changed to that of a child job). I'm guessing it was
evaluated from the last job/node to finish, but that wouldn't exactly explain
all the other times this has worked correctly.
was:
I have a diamond build setup that runs across several machines. The first job
runs on the parent node, then kicks off jobs on multiple child nodes, as well
as on itself...then a join build is done on a grandchild node.
I have a list of predefined parameters, one of which recently failed on me
unexpectedly:
TIMESTAMP=${BUILD_ID}_${NODE_NAME}
I expect these predefined parameters to evaluate on the parent node, where they
are configured (this is how they are evaluated on the pass-off to its
children). However, I just witnessed a grandchild build evaluate these
environment variables during the join action, from a child node (The build_id
and node_names were changed). I'm guessing it was evaluated from the last
job/node to finish, but that wouldn't exactly explain all the other times this
has worked correctly.
> Predefined parameters on a post-join build are evaluated by a child job
> rather than parent
> --
>
> Key: JENKINS-12686
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12686
> Project: Jenkins
> Issue Type: Bug
> Components: nodelabelparameter, parameterized-trigger
>Reporter: Michael Conlon
>Assignee: domi
>
> I have a diamond build setup that runs across several machines. The first job
> runs on the parent node, then kicks off jobs on multiple child nodes, as well
> as on itself...then a join build is done on a grandchild node.
> I have a list of predefined parameters, one of which recently failed on me
> unexpectedly:
> TIMESTAMP=${BUILD_ID}_${NODE_NAME}
> I expect these predefined parameters to evaluate on the parent node, where
> they are configured (this is how they are evaluated on the pass-off to its
> children). However, I just witnessed a grandchild build (during the join
> action) evaluate these environment variables from a child node (The build_id
> and node_names were changed to that of a child job). I'm guessing it was
> evaluated from the last job/node to finish, but that wouldn't exactly explain
> all the other times this has worked correctly.
--
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-8152) LDAP config error
[
https://issues.jenkins-ci.org/browse/JENKINS-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158793#comment-158793
]
SCM/JIRA link daemon commented on JENKINS-8152:
---
Code changed in jenkins
User: Stig Kleppe-Jørgensen
Path:
src/main/java/hudson/plugins/promoted_builds/Promotion.java
http://jenkins-ci.org/commit/promoted-builds-plugin/9b79be8796fe054ed02fa1d3ca01f57542e5fa83
Log:
Merge pull request #11 from ybonnel/master
[FIXES JENKINS-8152] Adds PROMOTED_ variables for SCM information
> LDAP config error
> -
>
> Key: JENKINS-8152
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8152
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
> Environment: Hudson 1.386; Windows XP; Hudson's built-in container
> (no Tomcat)
>Reporter: cjyar
>
> Configuring LDAP authentication in Hudson:
> Server: ldaps://directory.sri.com
> root DN: o=SRI International,c=US
> User search base:
> User search filter: uid={0}
> Group search base:
> Manager DN:
> Manager Password:
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'initialDirContextFactory': Instantiation of bean failed; nested
> exception is org.springframework.beans.BeanInstantiationException: Could not
> instantiate bean class
> [org.acegisecurity.ldap.DefaultInitialDirContextFactory]: Constructor threw
> exception; nested exception is java.lang.IllegalArgumentException: Root DNs
> must be the same when using multiple URLs
> at
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:231)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:957)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:869)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:514)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:485)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:169)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:170)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:413)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:735)
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:369)
> at
> hudson.util.spring.DefaultRuntimeSpringConfiguration.getApplicationContext(DefaultRuntimeSpringConfiguration.java:94)
> at
> hudson.util.spring.BeanBuilder.createApplicationContext(BeanBuilder.java:388)
> at
> hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:344)
> at
> hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:359)
> at hudson.security.HudsonFilter.reset(HudsonFilter.java:134)
> at hudson.model.Hudson.setSecurityRealm(Hudson.java:1833)
> at hudson.model.Hudson.doConfigSubmit(Hudson.java:2345)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
> at
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:102)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:562)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:640)
> at org.kohsuke
[JIRA] (JENKINS-9743) SVN_REVISION environment variable not available to promote build shell command
[
https://issues.jenkins-ci.org/browse/JENKINS-9743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158794#comment-158794
]
stigkj commented on JENKINS-9743:
-
This is fixed in [GitHub
commit|https://github.com/jenkinsci/promoted-builds-plugin/commit/9b79be8796fe054ed02fa1d3ca01f57542e5fa83]
> SVN_REVISION environment variable not available to promote build shell command
> --
>
> Key: JENKINS-9743
> URL: https://issues.jenkins-ci.org/browse/JENKINS-9743
> Project: Jenkins
> Issue Type: Bug
> Components: promoted-builds
> Environment: Centos, Java 6, Jenkins 1.410
>Reporter: Robert Elliot
>
> When adding a shell action to a promotion process on a job that is using
> subversion source control the SVN_REVISION environment variable is not
> provided. The BUILD_NUMBER environment variable is there and correct, so we
> can work around it as so:
> {noformat}export SVN_REVISION=`wget -qO-
> http:///job/spike-application/${BUILD_NUMBER}/api/xml?tree=changeSet[revisions[revision]]
> | grep -o "[0-9]\+"`
> echo PROMOTED ${SVN_REVISION} from unstable to stable{noformat}
> However, that's obviously horrible and given the BUILD_NUMBER is available it
> should be possible to retrieve the SVN_REVISION without an HTTP 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-4140) Hudson on Tomcat with SSL does not allow zipped artifact downloads in IE
[ https://issues.jenkins-ci.org/browse/JENKINS-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-4140. -- Resolution: Not A Defect > Hudson on Tomcat with SSL does not allow zipped artifact downloads in IE > > > Key: JENKINS-4140 > URL: https://issues.jenkins-ci.org/browse/JENKINS-4140 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: Windows XP >Reporter: oeuftete >Priority: Minor > > When Hudson is deployed on Tomcat with an SSL connector, zipped-up artifacts > can > not be downloaded when using IE. After investigating, it is clearly the issue > identified in Microsoft KB 316431: > http://support.microsoft.com/kb/316431 > Here are the headers that come back: > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Pragma: No-cache > Cache-Control: no-cache > Expires: Wed, 31 Dec 1969 19:00:00 EST > Content-Type: application/zip > Transfer-Encoding: chunked > Date: Thu, 30 Jul 2009 14:44:29 GMT > I am not a Tomcat or Java expert, so I'm not sure whose problem this is. Most > of the workarounds/solutions I found in searches were done on the application > side. I couldn't find a way to work around this in the main Tomcat > configuration. > If this is not an issue for the Hudson folks, please feel free to close this. > Thanks. -- 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-4140) Hudson on Tomcat with SSL does not allow zipped artifact downloads in IE
[ https://issues.jenkins-ci.org/browse/JENKINS-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158795#comment-158795 ] evernat commented on JENKINS-4140: -- As said in the Tomcat issue, fixes to workaround the MSIE issue were made elsewhere. It could be suggested to upgrade Tomcat. Without response to the previous question, resolving as not a defect (for Jenkins). > Hudson on Tomcat with SSL does not allow zipped artifact downloads in IE > > > Key: JENKINS-4140 > URL: https://issues.jenkins-ci.org/browse/JENKINS-4140 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: Windows XP >Reporter: oeuftete >Priority: Minor > > When Hudson is deployed on Tomcat with an SSL connector, zipped-up artifacts > can > not be downloaded when using IE. After investigating, it is clearly the issue > identified in Microsoft KB 316431: > http://support.microsoft.com/kb/316431 > Here are the headers that come back: > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Pragma: No-cache > Cache-Control: no-cache > Expires: Wed, 31 Dec 1969 19:00:00 EST > Content-Type: application/zip > Transfer-Encoding: chunked > Date: Thu, 30 Jul 2009 14:44:29 GMT > I am not a Tomcat or Java expert, so I'm not sure whose problem this is. Most > of the workarounds/solutions I found in searches were done on the application > side. I couldn't find a way to work around this in the main Tomcat > configuration. > If this is not an issue for the Hudson folks, please feel free to close this. > Thanks. -- 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-3242) Classloader isolation of m2 build on tomcat. (JDK 1.5 m2 build on Tomcat 6 (JDK 1.6) on Ubuntu 8.10)
[ https://issues.jenkins-ci.org/browse/JENKINS-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-3242. -- Resolution: Incomplete No response and seems to be fixed elsewhere, resolving as incomplete. > Classloader isolation of m2 build on tomcat. (JDK 1.5 m2 build on Tomcat 6 > (JDK 1.6) on Ubuntu 8.10) > > > Key: JENKINS-3242 > URL: https://issues.jenkins-ci.org/browse/JENKINS-3242 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: PC, OS: Linux >Reporter: buckett > > I was attempting to run hudson inside a copy of Tomcat 6 using JDK 1.6 on > Ubuntu > 8.10 and run a Maven 2 build with JDK 1.5. As soon as hudson tried to archive > the first pom encountered it blows up with the stack trace: > [INFO] Trace > java.lang.UnsupportedClassVersionError: Bad version number in .class file > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at java.lang.ClassLoader.defineClass(ClassLoader.java:465) > at > hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:96) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at hudson.FilePath.act(FilePath.java:434) > at hudson.FilePath.copyTo(FilePath.java:869) > at hudson.FilePath.copyTo(FilePath.java:857) > at hudson.maven.reporters.MavenArtifact.archive(MavenArtifact.java:184) > at > hudson.maven.reporters.MavenArtifactArchiver.postBuild(MavenArtifactArchiver.java:107) > at > hudson.maven.MavenModuleSetBuild$Builder.postModule(MavenModuleSetBuild.java:612) > at > hudson.maven.MavenBuilder$Adapter.fireLeaveModule(MavenBuilder.java:307) > at hudson.maven.MavenBuilder$Adapter.postBuild(MavenBuilder.java:265) > at > org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:68) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at hudson.maven.agent.Main.launch(Main.java:158) > at hudson.maven.MavenBuilder.call(MavenBuilder.java:162) > at > hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:579) > at > hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:525) > at hudson.remoting.UserRequest.perform(UserRequest.java:92) > at hudson.remoting.UserRequest.perform(UserRequest.java:46) > at hudson.remoting.Request$2.run(Request.java:236) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) > at java.util.concurrent.FutureTask.run(FutureTask.java:123) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) > at java.lang.Thread.run(Thread.java:595) > The reason is that on Ubuntu 8.10 they compile Tomcat 6 on JDK 1.6 so all the > tomcat classfiles have a version requirement of 50 (JDK 1.6). > It seems that the classloader of the servlet container is used during the > maven > build which causes this issue. I wouldn't have expected the build to have > access > to any classes of the container that is was running in. -- 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-12673) Can't install apk and adb devices shows there is no device/emulator
[ https://issues.jenkins-ci.org/browse/JENKINS-12673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Chow closed JENKINS-12673. Resolution: Cannot Reproduce > Can't install apk and adb devices shows there is no device/emulator > --- > > Key: JENKINS-12673 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12673 > Project: Jenkins > Issue Type: New Feature > Components: android-emulator > Environment: OSX >Reporter: Kevin Chow >Assignee: Christopher Orr > > I use Install Android Package Option in Build Step > Before running the installer, I did adb devices and it's showing the emulator > + /tmp/jenkins/tools/android-sdk/platform-tools/adb devices > 15:50:37 List of devices attached > 15:50:37 localhost:49651 device > 15:50:37 > 15:50:37 [android] Installing APK file 'EM_Runtime.apk' > 15:50:37 $ /tmp/jenkins/tools/android-sdk/platform-tools/adb -s > localhost:49651 install -r Runtime.apk > 15:50:47 729 KB/s (7369965 bytes in 9.870s) > 15:50:50 pkg: /data/local/tmp/Runtime.apk > 15:51:27 - waiting for device - > It's supposed to show "Succeed" which is not. I tried to run this again: > + /tmp/jenkins/tools/android-sdk/platform-tools/adb devices > It would just restart adb. > Is it a known issue? Anyway that I could resolve it? -- 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-12673) Can't install apk and adb devices shows there is no device/emulator
[ https://issues.jenkins-ci.org/browse/JENKINS-12673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158797#comment-158797 ] Kevin Chow commented on JENKINS-12673: -- Hi Chris, Yes, I am using the plugin. The plugin version is 2.1 I found that it fails in the first time. When it's relaunched and disabled "Reset emulator state at start-up", it works fine again. I'm closing out this issue for now. > Can't install apk and adb devices shows there is no device/emulator > --- > > Key: JENKINS-12673 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12673 > Project: Jenkins > Issue Type: New Feature > Components: android-emulator > Environment: OSX >Reporter: Kevin Chow >Assignee: Christopher Orr > > I use Install Android Package Option in Build Step > Before running the installer, I did adb devices and it's showing the emulator > + /tmp/jenkins/tools/android-sdk/platform-tools/adb devices > 15:50:37 List of devices attached > 15:50:37 localhost:49651 device > 15:50:37 > 15:50:37 [android] Installing APK file 'EM_Runtime.apk' > 15:50:37 $ /tmp/jenkins/tools/android-sdk/platform-tools/adb -s > localhost:49651 install -r Runtime.apk > 15:50:47 729 KB/s (7369965 bytes in 9.870s) > 15:50:50 pkg: /data/local/tmp/Runtime.apk > 15:51:27 - waiting for device - > It's supposed to show "Succeed" which is not. I tried to run this again: > + /tmp/jenkins/tools/android-sdk/platform-tools/adb devices > It would just restart adb. > Is it a known issue? Anyway that I could resolve it? -- 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-9862) Selenium Grid does not work latest version of Firefox
[ https://issues.jenkins-ci.org/browse/JENKINS-9862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Lavoie reassigned JENKINS-9862: --- Assignee: Richard Lavoie (was: Kohsuke Kawaguchi) > Selenium Grid does not work latest version of Firefox > - > > Key: JENKINS-9862 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9862 > Project: Jenkins > Issue Type: Bug > Components: selenium >Affects Versions: current > Environment: Windows 2003 SP2 >Reporter: apgray >Assignee: Richard Lavoie >Priority: Critical > Fix For: current > > > When I upgrade to latest version of FF (currently 4.0.1), Selenium Tests > refuse to drive the browser. If I downgrade to FF3.5.x Selenium tests work > again. -- 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-12463) Selenium grid v2 could have different configuration per slave
[ https://issues.jenkins-ci.org/browse/JENKINS-12463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Lavoie reassigned JENKINS-12463: Assignee: Richard Lavoie (was: Kohsuke Kawaguchi) > Selenium grid v2 could have different configuration per slave > - > > Key: JENKINS-12463 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12463 > Project: Jenkins > Issue Type: Improvement > Components: master-slave, selenium >Reporter: Richard Lavoie >Assignee: Richard Lavoie > > When running slaves with the selenium grid v2 plugin, each slave could have > different configuration (some not supporting IE on linux, or not chrome). The > suggestion here is to be able to configure the grid v2 configuration per > slave. Not only on the master. -- 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-9117) Jenkins hangs in the shutdown mode after thinBackup is triggered
[ https://issues.jenkins-ci.org/browse/JENKINS-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158798#comment-158798 ] Mingjiang Shi commented on JENKINS-9117: @Thomas Fürer, If a time-consuming job is triggered, the message "Jenkins is going to shutdown" will be displayed. After I disabled the plugin, the message is not displayed any more. Please let me know what information you need to diagnose the issue. This is a very annoying issue. > Jenkins hangs in the shutdown mode after thinBackup is triggered > > > Key: JENKINS-9117 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9117 > Project: Jenkins > Issue Type: Bug > Components: thinBackup >Reporter: Thomas Fürer >Assignee: Thomas Fürer > > thinBackup triggers a backup job and did not return from the shutdown mode -- 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-11743) selenium plugin -- slaves/remote control servers stay in "in use" status even they are not really "in use"
[ https://issues.jenkins-ci.org/browse/JENKINS-11743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158799#comment-158799 ] Richard Lavoie commented on JENKINS-11743: -- The problem is not solely related to the jenkins plugin. If your tests don't close/quit the browser at the end, selenium nodes think they are still having a session which is what jenkins plugin uses to validate if it's in use. Thankfully, there is actually a way to tell the nodes to close the browsers when they didn't receive a command after a while thus closing dangling sessions/browsers. The current plugin doesn't support that option yet (-timeout) but there is an an opened issue I'm currently working on to improve node configurations which will include that option. See https://issues.jenkins-ci.org/browse/JENKINS-12463 > selenium plugin -- slaves/remote control servers stay in "in use" status even > they are not really "in use" > -- > > Key: JENKINS-11743 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11743 > Project: Jenkins > Issue Type: Bug > Components: selenium >Affects Versions: current > Environment: jenkins 1.437 > selenium plugin 1.4 > OS: CentOS release 5.7 (Final) >Reporter: hinling yeung >Assignee: Kohsuke Kawaguchi > > I have been running into this problem ever since I switched to use the > jenkins selenium plugin as my grid. After the grid has been running for a > while, the slaves/rc servers which are connected to the grid start to appear > as "in use". When I logged on to the rc servers to check whether they are > actually "in use", they were actually idle with the browser windows still > open but not doing anything. I checked the RC log and it usually stuck at > "Slave successfully connected": > JNLP agent connected from /10.1.104.72 > <===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 2.11 > This is a Windows slave > Copied maven-agent.jar > Copied maven3-agent.jar > Copied maven3-interceptor.jar > Copied maven-interceptor.jar > Copied maven2.1-interceptor.jar > Copied plexus-classworld.jar > Copied classworlds.jar > Slave successfully connected and online > When this happens, it happens to all the RCs. I have to restart the jenkins > server to get out of this "in use" state. -- 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-11743) selenium plugin -- slaves/remote control servers stay in "in use" status even they are not really "in use"
[ https://issues.jenkins-ci.org/browse/JENKINS-11743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Lavoie reassigned JENKINS-11743: Assignee: Richard Lavoie (was: Kohsuke Kawaguchi) > selenium plugin -- slaves/remote control servers stay in "in use" status even > they are not really "in use" > -- > > Key: JENKINS-11743 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11743 > Project: Jenkins > Issue Type: Bug > Components: selenium >Affects Versions: current > Environment: jenkins 1.437 > selenium plugin 1.4 > OS: CentOS release 5.7 (Final) >Reporter: hinling yeung >Assignee: Richard Lavoie > > I have been running into this problem ever since I switched to use the > jenkins selenium plugin as my grid. After the grid has been running for a > while, the slaves/rc servers which are connected to the grid start to appear > as "in use". When I logged on to the rc servers to check whether they are > actually "in use", they were actually idle with the browser windows still > open but not doing anything. I checked the RC log and it usually stuck at > "Slave successfully connected": > JNLP agent connected from /10.1.104.72 > <===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 2.11 > This is a Windows slave > Copied maven-agent.jar > Copied maven3-agent.jar > Copied maven3-interceptor.jar > Copied maven-interceptor.jar > Copied maven2.1-interceptor.jar > Copied plexus-classworld.jar > Copied classworlds.jar > Slave successfully connected and online > When this happens, it happens to all the RCs. I have to restart the jenkins > server to get out of this "in use" state. -- 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-12080) job configuration corrupted when user isn't admin
[ https://issues.jenkins-ci.org/browse/JENKINS-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158800#comment-158800 ] SCM/JIRA link daemon commented on JENKINS-12080: Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/groovy/SystemGroovy.java src/main/resources/hudson/plugins/groovy/SystemGroovy/config.jelly src/main/webapp/systemscript-projectconfig.html http://jenkins-ci.org/commit/groovy-plugin/d40a525294b920e11ba388060b58111c19f5c337 Log: [FIXED JENKINS-12080] use a hidden, encrypted field to store configured script when user isn't admin > job configuration corrupted when user isn't admin > - > > Key: JENKINS-12080 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12080 > Project: Jenkins > Issue Type: Bug > Components: groovy >Reporter: Nicolas De Loof >Assignee: vjuranek > > Let's consider : > - a user with job configuration rights and no overall admin right > - a job containing a system groovy build step > If the user edits the configuration, makes a change (even without altering > the system groovy part) and then saves the configuration, an error message is > displayed : > Access Denied > is missing the Administer permission > On Job save, Groovy plugin checks for admin permission to save the system > groovy script. It may then fail. This should have been checked before > rendering UI. The side effect is that the job config is partially saved > (without user to know it) and may be corrupted (exception occurs on > Project.submit() from builders.rebuildHetero, so job has been partially > configured and not saved. > The job configuration page, when including a system groovy script, should not > be editable when user don't have ADMIN permission - Not sure about the > cleaner way to implement the ADMIN only configuration > OR the script should be set read-only for non ADMIN and then only displayed > for information, but retrieved from another source than the standard incoming > JSON 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-12080) job configuration corrupted when user isn't admin
[ https://issues.jenkins-ci.org/browse/JENKINS-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12080. Resolution: Fixed > job configuration corrupted when user isn't admin > - > > Key: JENKINS-12080 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12080 > Project: Jenkins > Issue Type: Bug > Components: groovy >Reporter: Nicolas De Loof >Assignee: vjuranek > > Let's consider : > - a user with job configuration rights and no overall admin right > - a job containing a system groovy build step > If the user edits the configuration, makes a change (even without altering > the system groovy part) and then saves the configuration, an error message is > displayed : > Access Denied > is missing the Administer permission > On Job save, Groovy plugin checks for admin permission to save the system > groovy script. It may then fail. This should have been checked before > rendering UI. The side effect is that the job config is partially saved > (without user to know it) and may be corrupted (exception occurs on > Project.submit() from builders.rebuildHetero, so job has been partially > configured and not saved. > The job configuration page, when including a system groovy script, should not > be editable when user don't have ADMIN permission - Not sure about the > cleaner way to implement the ADMIN only configuration > OR the script should be set read-only for non ADMIN and then only displayed > for information, but retrieved from another source than the standard incoming > JSON 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-12080) job configuration corrupted when user isn't admin
[ https://issues.jenkins-ci.org/browse/JENKINS-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158801#comment-158801 ] dogfood commented on JENKINS-12080: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_groovy #57|http://ci.jenkins-ci.org/job/plugins_groovy/57/] [FIXED JENKINS-12080] use a hidden, encrypted field to store configured script when user isn't admin (Revision d40a525294b920e11ba388060b58111c19f5c337) Result = SUCCESS Nicolas De Loof : Files : * src/main/java/hudson/plugins/groovy/SystemGroovy.java * src/main/resources/hudson/plugins/groovy/SystemGroovy/config.jelly * src/main/webapp/systemscript-projectconfig.html > job configuration corrupted when user isn't admin > - > > Key: JENKINS-12080 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12080 > Project: Jenkins > Issue Type: Bug > Components: groovy >Reporter: Nicolas De Loof >Assignee: vjuranek > > Let's consider : > - a user with job configuration rights and no overall admin right > - a job containing a system groovy build step > If the user edits the configuration, makes a change (even without altering > the system groovy part) and then saves the configuration, an error message is > displayed : > Access Denied > is missing the Administer permission > On Job save, Groovy plugin checks for admin permission to save the system > groovy script. It may then fail. This should have been checked before > rendering UI. The side effect is that the job config is partially saved > (without user to know it) and may be corrupted (exception occurs on > Project.submit() from builders.rebuildHetero, so job has been partially > configured and not saved. > The job configuration page, when including a system groovy script, should not > be editable when user don't have ADMIN permission - Not sure about the > cleaner way to implement the ADMIN only configuration > OR the script should be set read-only for non ADMIN and then only displayed > for information, but retrieved from another source than the standard incoming > JSON 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-12583) update for cvs plugin to 2.0 doesn't work
[ https://issues.jenkins-ci.org/browse/JENKINS-12583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158802#comment-158802 ] Sergey Bushov commented on JENKINS-12583: - I'm also not able to update from 1.6 to 2.0, and the workaround does not work for me. I don't see the mentioned exceptions/errors in log, but the plugin stays on version 1.6 after update. > update for cvs plugin to 2.0 doesn't work > - > > Key: JENKINS-12583 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12583 > Project: Jenkins > Issue Type: Bug > Components: cvs >Affects Versions: current > Environment: jenkins 1.449, cvs plugin 1.6 >Reporter: Alex Lehmann > Fix For: current > > > I tried to update to the cvs plugin 2.0 today but this doesn't work, I assume > there is a name problem due to the extension *.jpi on the new plugin. > Before update, the file is called cvs.hpi, the update process creates a new > file cvs.jpi that is ignored with the following message: > Jan 30, 2012 5:04:26 PM hudson.PluginManager$1$3$1 isDuplicate > INFO: Ignoring /home/lehmann/.jenkins/plugins/cvs.jpi because > /home/lehmann/.jenkins/plugins/cvs.hpi is already loaded > I assume it may work if it were the other way around. > The version displayed by the plugin page remains 1.6 but there are a few > exceptions in the log about missing classes like this > java.lang.NoClassDefFoundError: org/netbeans/lib/cvsclient/admin/AdminHandler > these classes are included in the cvs.jpi zip but that is not used. > I was able to fix the update manually by copying cvs.jpi to cvs.hpi, which > resulted in a pinned plugin 2.0, but the automatic process has to be fixed > somehow. -- 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
