[JIRA] [multijob-plugin] (JENKINS-30580) Trigger MultiJob Plugin Phases upon Job Completion
Title: Message Title Christian Goetze commented on JENKINS-30580 Re: Trigger MultiJob Plugin Phases upon Job Completion https://gist.github.com/cg-soft/0ac60a9720662a417cfa is my current solution, but I wished I could create those nice status pages directly on the build page in Jenkins. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-30707) Running scheduleBuild from system groovy script crashes Jenkins
Title: Message Title Christian Goetze commented on JENKINS-30707 Re: Running scheduleBuild from system groovy script crashes Jenkins I guess the issue is that if the script launching these jobs is aborted, the threads running those scripts suddenly become orphaned. It might be nice if the groovy excutor could reap those threads in some manner. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-30707) Running scheduleBuild from system groovy script crashes Jenkins
Title: Message Title
Christian Goetze created an issue
Jenkins / JENKINS-30707
Running scheduleBuild from system groovy script crashes Jenkins
Issue Type:
Bug
Assignee:
vjuranek
Components:
core, groovy-plugin
Created:
29/Sep/15 8:28 PM
Environment:
version 1.620
Priority:
Major
Reporter:
Christian Goetze
I am using a system groovy script to launch jenkins jobs as follows:
def job = hudson.model.Hudson.instance.getJob(jobData['JobName'])
def params = jobData['Parameters'].collect { key, val -> new hudson.model.StringParameterValue(key, val) }
def paramsAction = new hudson.model.ParametersAction(params)
def cause = new hudson.model.Cause.UpstreamCause(build)
def causeAction = new hudson.model.CauseAction(cause)
hudson.model.Hudson.instance.queue.schedule(job, 0, causeAction, paramsAction)
This works fine, except if the system groovy script crashes or gets aborted. Then suddenly Jenkins appears to go into a death spiral, with the UI slowing down to a crawl and eventually crashing.
[JIRA] [multijob-plugin] (JENKINS-30580) Trigger MultiJob Plugin Phases upon Job Completion
Title: Message Title
Christian Goetze commented on JENKINS-30580
Re: Trigger MultiJob Plugin Phases upon Job Completion
Currently, the multijob plugin allows you to group sub-jobs into phases, which get executed sequentially:
phase1 {
left1()
right1()
...
}
phase2 {
left2()
right2()
...
}
phase3 {
aggregate()
}
In this example, phase1 will launch left1() and right1(), phase2 will wait until left1() and right1() completes and then launch left2() and right2(). phase3 waits until phase2 completes, then launches aggregate().
The desired modification is to add a property to the phase which explicitly lists the jobs to wait on prior to launching, so, for example, in this case we would say:
leftPhase1 {
left1()
}
leftPhase2(waitFor: [ left1 ]) {
left2()
}
rightPhase1 {
right1()
}
rightPhase2(waitFor: [ right1 ]) {
right2()
}
aggregatePhase(waitFor: [ left2, right2 ]) {
aggregate()
}
This means that multiple phases can be running at a given time.
Launching new jobs as soon as their prerequisite jobs complete will generally lead to a better schedule than having to lockstep the phases, and is certainly better than linearizing the build. It is easy to see that the new method will always deliver the shortest build time as long as sufficient executors are available. Since we are usually not too much constrained by the number of executors, this will most certainly improve build times.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [multijob-plugin] (JENKINS-30580) Trigger MultiJob Plugin Phases upon Job Completion
Title: Message Title Christian Goetze created an issue Jenkins / JENKINS-30580 Trigger MultiJob Plugin Phases upon Job Completion Issue Type: New Feature Assignee: Unassigned Components: multijob-plugin Created: 21/Sep/15 10:22 PM Priority: Minor Reporter: Christian Goetze See http://stackoverflow.com/questions/32704360/how-can-i-trigger-a-jenkins-job-upon-completion-of-a-set-of-other-jobs What I would love to see is the possibility to add a list of jobs to a phase definition, and the phase would start not when the previous phase is completed, but as a soon as all the jobs listed complete. Is this very hard to do? Add Comment
[JIRA] [job-dsl-plugin] (JENKINS-29662) Job DSL downstreamParameterized blockingThresholds 'never' option not available
Title: Message Title Christian Goetze commented on JENKINS-29662 Re: Job DSL downstreamParameterized blockingThresholds 'never' option not available It would be nice if this could be fixed. Maybe distinguish between passing in null vs an empty list, where null gets us the default settings and the empty list gets us never everywhere? The reason we need it is because I want to be able to launch a sub-job and have it absolutely not affect the parent job in any way, regardless of success or failure of the sub-job. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-28123) Jobs stay queued forever if a node with the label is initially unavailable
Title: Message Title Christian Goetze commented on JENKINS-28123 Re: Jobs stay queued forever if a node with the label is initially unavailable I did check what it does: https://groups.google.com/forum/#!topic/jenkinsci-users/-4S9VYbocyA Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-28123) Jobs stay queued forever if a node with the label is initially unavailable
Title: Message Title
Christian Goetze commented on JENKINS-28123
Re: Jobs stay queued forever if a node with the label is initially unavailable
I run that snippet I showed:
jenkins.model.Jenkins.instance.labels.each { it.reset() }
I'll check what trimLabels() does...
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-28123) Jobs stay queued forever if a node with the label is initially unavailable
Title: Message Title Christian Goetze commented on JENKINS-28123 Re: Jobs stay queued forever if a node with the label is initially unavailable Actually, that's the point, it didn't appear to work. This being said, this isn't an urgent issue for me anymore, as I simply split the job into two separate jobs with their custom static label setting. Since I generate the jobs via the job DSL plugin, it's no big deal for me. The label assignment plugin failure mode makes it too risky to expose. I spend a whole night debugging the wrong job (the parent job trying to launch it) until I figured out it was the child job's label assignment plugin. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-28123) Jobs stay queued forever if a node with the label is initially unavailable
Title: Message Title Christian Goetze commented on JENKINS-28123 Re: Jobs stay queued forever if a node with the label is initially unavailable Maybe the manual change of the node label does additional activation? In my case, it is a groovy script which changes the node labels. I observed that static Restrict where this can run behave correctly, but the groovy script doesn't. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-failure-analyzer-plugin] (JENKINS-28273) Failure explanation text not sanitized prior to issuing gerrit review command
Title: Message Title
Christian Goetze updated an issue
Jenkins / JENKINS-28273
Failure explanation text not sanitized prior to issuing gerrit review command
Change By:
Christian Goetze
Ifthetextualdescriptionofthebuildfailurecausecontainsasinglequote,thenthenotificationcommandtogerritwillfail.Forexample:{noformat}SEVERE:Couldnotruncommandgerritreview42422,1--message'BuildFailedhttp://leeroy-jenkins/job/some-job:SUCCESShttp://leeroy-jenkins/job/some-other-job:FAILUREGradlecouldn'tsuccessfullybuildyourtarget.(http://leeroy-jenkins//job/some-other-job)http://leeroy-jenkins/job/ gerrit yet - controller another - uxbuild-sanity/16467/ build :SUCCESS'--verified-1--code-review0java.io.IOException:ErrorduringsendingcommandatstacktraceCausedby:com.sonymobile.tools.gerrit.gerritevents.ssh.SshException:fatal:successfullyisnotavalidpatchset(1)atcom.sonymobile.tools.gerrit.gerritevents.ssh.SshConnectionImpl.executeCommand(SshConnectionImpl.java:253){noformat}{noformat}
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-failure-analyzer-plugin] (JENKINS-28273) Failure explanation text not sanitized prior to issuing gerrit review command
Title: Message Title Christian Goetze created an issue Jenkins / JENKINS-28273 Failure explanation text not sanitized prior to issuing gerrit review command Issue Type: Bug Assignee: Tomas Westling Components: build-failure-analyzer-plugin, gerrit-plugin Created: 06/May/15 5:59 PM Priority: Major Reporter: Christian Goetze If the textual description of the build failure cause contains a single quote, then the notification command to gerrit will fail. For example: SEVERE: Could not run command gerrit review 42422,1 --message 'Build Failed http://leeroy-jenkins/job/some-job : SUCCESS http://leeroy-jenkins/job/some-other-job: FAILURE Gradle couldn't successfully build your target. ( http://leeroy-jenkins//job/some-other-job ) http://leeroy-jenkins/job/gerrit-controller-uxbuild-sanity/16467/ : SUCCESS' --verified -1 --code-review 0 java.io.IOException: Error during sending command at stack trace Caused by: com.sonymobile.tools.gerrit.gerritevents.ssh.SshException: fatal: successfully is not a valid patch set (1) at com.sonymobile.tools.gerrit.gerritevents.ssh.SshConnectionImpl.executeCommand(SshConnectionImpl.java:253)
[JIRA] [groovy-label-assignment-plugin] (JENKINS-28123) Jobs stay queued forever if label assignment is initially unavailable
Christian Goetze
commented on JENKINS-28123
Jobs stay queued forever if label assignment is initially unavailable
The way a node can become available is also via a script, which modifies the labels on nodes and then runs:
jenkins.model.Jenkins.instance.labels.each { it.reset() }
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [groovy-label-assignment-plugin] (JENKINS-28123) Jobs stay queued forever if label assignment is initially unavailable
Christian Goetze created JENKINS-28123 Jobs stay queued forever if label assignment is initially unavailable Issue Type: Bug Assignee: Unassigned Components: groovy-label-assignment-plugin Created: 27/Apr/15 10:59 PM Description: If a job sets a label and no node is available to run the job, the job just stays queued forever even if an appropriate node later becomes available. Is there some (groovy) way to "tickle" the job in the queue? Project: Jenkins Priority: Minor Reporter: Christian Goetze This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [groovy-label-assignment-plugin] (JENKINS-28123) Jobs stay queued forever if label assignment is initially unavailable
Christian Goetze commented on JENKINS-28123 Jobs stay queued forever if label assignment is initially unavailable See also: http://stackoverflow.com/questions/29907462/jobs-using-groovy-label-assignment-plugin-stay-queued-forever-if-no-slave-is-ini This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-26744) Support ALWAYS Continuation Condition in Multi-Phase Jobs
Christian Goetze commented on JENKINS-26744 Support ALWAYS Continuation Condition in Multi-Phase Jobs Falls Du mal nach San Francisco kommst, gibt es definitiv Bier! Vielen Dank This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-27594) Jetty based jenkins leaves many sockets in close_wait state
Christian Goetze created JENKINS-27594 Jetty based jenkins leaves many sockets in close_wait state Issue Type: Bug Assignee: Unassigned Components: core Created: 25/Mar/15 4:23 PM Description: I woke up one morning and the jenkins UI was unavailable. Logs show that it was still processing builds. lsof revealed a lot of hanging connections: java 2559 jenkins 1314u IPv6 240423343 0t0TCP localhost:webcache-localhost:54609 (CLOSE_WAIT) java 2559 jenkins 1315w IPv6 240423345 0t0TCP localhost:webcache-localhost:39608 (CLOSE_WAIT) java 2559 jenkins 1316u IPv6 240423348 0t0TCP localhost:webcache-localhost:39609 (CLOSE_WAIT) java 2559 jenkins 1317u IPv6 240423351 0t0TCP localhost:webcache-localhost:54613 (CLOSE_WAIT) java 2559 jenkins 1318u IPv6 240423354 0t0TCP localhost:webcache-localhost:39612 (CLOSE_WAIT) java 2559 jenkins 1319u IPv6 240423358 0t0TCP localhost:webcache-localhost:39613 (CLOSE_WAIT) java 2559 jenkins 1320u IPv6 240423360 0t0TCP localhost:webcache-localhost:39614 (CLOSE_WAIT) java 2559 jenkins 1321u IPv6 240423362 0t0TCP localhost:webcache-localhost:54621 (CLOSE_WAIT) There were almost 700 of these. Restarting jenkins cleared the problem, but this very disruptive. What's going on? Project: Jenkins Priority: Major Reporter: Christian Goetze This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-26744) Support ALWAYS Continuation Condition in Multi-Phase Jobs
Christian Goetze commented on JENKINS-26744 Support ALWAYS Continuation Condition in Multi-Phase Jobs I guess if I want this fixed, I need to fork and contribute, eh? Can I buy you a beer instead, please This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-26744) Support ALWAYS Continuation Condition in Multi-Phase Jobs
Christian Goetze created JENKINS-26744 Support ALWAYS Continuation Condition in Multi-Phase Jobs Issue Type: New Feature Assignee: Daniel Spilker Components: job-dsl-plugin Created: 03/Feb/15 12:09 AM Description: Jenkins UI supports it, so why not Job-DSL? Any attempt to use that results in a stack trace: 16:01:19 FATAL: Continuation Condition needs to be one of these values: SUCCESSFUL, UNSTABLE, COMPLETED 16:01:19 java.lang.IllegalArgumentException: Continuation Condition needs to be one of these values: SUCCESSFUL, UNSTABLE, COMPLETED 16:01:19 at com.google.common.base.Preconditions.checkArgument(Preconditions.java:92) 16:01:19 at com.google.common.base.Preconditions$checkArgument.call(Unknown Source) 16:01:19 at javaposse.jobdsl.dsl.helpers.step.StepContext.phase(StepContext.groovy:571) 16:01:19 at javaposse.jobdsl.dsl.helpers.step.StepContext$phase.callCurrent(Unknown Source) 16:01:19 at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46) ... Project: Jenkins Priority: Minor Reporter: Christian Goetze This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [slave-squatter] (JENKINS-24449) slave cleanup causes jobs to hang
Christian Goetze commented on JENKINS-24449 slave cleanup causes jobs to hang Probably not, it's "just" a rather nasty slave.jar bug. I can never figure out what tag to use... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24449) slave cleanup causes jobs to hang
Christian Goetze updated JENKINS-24449 slave cleanup causes jobs to hang Change By: Christian Goetze (27/Aug/14 6:26 AM) Component/s: core Component/s: slave-squatter This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [slave-squatter] (JENKINS-24449) slave cleanup causes jobs to hang
Christian Goetze created JENKINS-24449 slave cleanup causes jobs to hang Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: slave-squatter Created: 26/Aug/14 5:33 PM Description: I observe that jobs starting at the same time the slave is performing some sort of cleanup action hang: Build Log: 17:04:21 Started by upstream project "pipeline-test-2" build number 422 17:04:21 originally caused by: 17:04:21 Started by upstream project "master-test" build number 867 17:04:21 originally caused by: 17:04:21 Started by upstream project "master-build" build number 5131 17:04:21 originally caused by: 17:04:21Started by an SCM change 17:04:21 [EnvInject] - Loading node environment variables. ... hang for 14h ... Slave Log: ... lots of output ... INFO: Deleting /tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.appdynamics.com_10002/lib/jboss-j2se.jar (atime=1408400947, diff=-5424) Aug 25, 2014 5:01:12 PM hudson.plugins.tmpcleaner.TmpCleanTask visit INFO: Deleting /tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.appdynamics.com_10002/lib/javassist.jar (atime=1408400947, diff=-5424) Aug 25, 2014 5:01:12 PM hudson.plugins.tmpcleaner.TmpCleanTask visit INFO: Deleting /tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.appdynamics.com_10002/lib/jboss-system-jmx.jar (atime=1408400947, diff=-5424) Aug 25, 2014 5:01:12 PM hudson.plugins.tmpcleaner.TmpCleanTask visit INFO: Deleting /tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.appdynamics.com_10002/lib/jboss-system.jar (atime=1408400947, diff=-5424) Aug 25, 2014 5:01:12 PM hudson.plugins.tmpcleaner.TmpCleanTask visit INFO: Deleting /tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.appdynamics.com_10002/lib/jboss-mdr.jar (atime=1408400947, diff=-5424) Aug 25, 2014 5:01:12 PM hudson.plugins.tmpcleaner.TmpCleanTask visit INFO: Deleting /tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.appdynamics.com_10002/lib/jboss-logging-spi.jar (atime=1408400947, diff=-5424) Aug 25, 2014 5:01:12 PM hudson.plugins.tmpcleaner.TmpCleanTask visit After interrupting the job, I get this: 0:30:26 ERROR: SEVERE ERROR occurs 10:30:26 org.jenkinsci.lib.envinject.EnvInjectException: java.lang.InterruptedException 10:30:26 at org.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvironmentVariablesNode(EnvironmentVariablesNodeLoader.java:77) 10:30:26 at org.jenkinsci.plugins.envinject.EnvInjectListener.loadEnvironmentVariablesNode(EnvInjectListener.java:81) 10:30:26 at org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:39) 10:30:26 at hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:575) 10:30:26 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:481) 10:30:26 at hudson.model.Run.execute(Run.java:1689) 10:30:26 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 10:30:26 at hudson.model.ResourceController.execute(ResourceController.java:88) 10:30:26 at hudson.model.Executor.run(Executor.java:231) 10:30:26 Caused by: java.lang.InterruptedException 10:30:26 at java.lang.Object.wait(Native Method) 10:30:26 at hudson.remoting.Request.call(Request.java:146) 10:30:26 at hudson.remoting.Channel.call(Channel.java:722) 10:30:26 at hudson.FilePath.act(FilePath.java:1003) 10:30:26 at org.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvironmentVariablesNode(EnvironmentVariablesNodeLoader.java:44) 10:30:26 ... 8 more 10:30:26 Archiving artifacts 10:30:26 ERROR: Publisher hudson.tasks.Mailer aborted due to exception 10:30:26 hudson.remoting.ChannelClosedException: channel is already closed 10:30:26 at hudson.remoting.Channel.send(Channel.java:524) 10:30:26 at hudson.remoting.Request.call(Request.java:129) 10:30:26 at hudson.remoting.Channel.call(Channel.java:722) 10:30:26 at hudson.EnvVars.getRemote(EnvVars.java:404) 10:30:26 at hudson.model.Computer.getEnvironment(Computer.java:911) 10:30:26 at
[JIRA] [slave-squatter] (JENKINS-24449) slave cleanup causes jobs to hang
Christian Goetze
updated JENKINS-24449
slave cleanup causes jobs to hang
Change By:
Christian Goetze
(26/Aug/14 5:34 PM)
Description:
Iobservethatjobsstartingatthesametimetheslaveisperformingsomesortofcleanupactionhang:BuildLog:{noformat}17:04:21Startedbyupstreamprojectpipeline-test-2buildnumber42217:04:21originallycausedby:17:04:21Startedbyupstreamprojectmaster-testbuildnumber86717:04:21originallycausedby:17:04:21Startedbyupstreamprojectmaster-buildbuildnumber513117:04:21originallycausedby:17:04:21StartedbyanSCMchange17:04:21[EnvInject]-Loadingnodeenvironmentvariableshangfor14h...{noformat}SlaveLog:{noformat}...lotsofoutput...INFO:Deleting/tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.
appdynamics
XXX
.com_10002/lib/jboss-j2se.jar(atime=1408400947,diff=-5424)Aug25,20145:01:12PMhudson.plugins.tmpcleaner.TmpCleanTaskvisitINFO:Deleting/tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.
appdynamics
XXX
.com_10002/lib/javassist.jar(atime=1408400947,diff=-5424)Aug25,20145:01:12PMhudson.plugins.tmpcleaner.TmpCleanTaskvisitINFO:Deleting/tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.
appdynamics
XXX
.com_10002/lib/jboss-system-jmx.jar(atime=1408400947,diff=-5424)Aug25,20145:01:12PMhudson.plugins.tmpcleaner.TmpCleanTaskvisitINFO:Deleting/tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.
appdynamics
XXX
.com_10002/lib/jboss-system.jar(atime=1408400947,diff=-5424)Aug25,20145:01:12PMhudson.plugins.tmpcleaner.TmpCleanTaskvisitINFO:Deleting/tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.
appdynamics
XXX
.com_10002/lib/jboss-mdr.jar(atime=1408400947,diff=-5424)Aug25,20145:01:12PMhudson.plugins.tmpcleaner.TmpCleanTaskvisitINFO:Deleting/tmp/1408400946520-0/jboss51x_centos5-x64-bld-slave-09.corp.
appdynamics
XXX
.com_10002/lib/jboss-logging-spi.jar(atime=1408400947,diff=-5424)Aug25,20145:01:12PMhudson.plugins.tmpcleaner.TmpCleanTaskvisit{noformat}Afterinterruptingthejob,Igetthis:{noformat}0:30:26ERROR:SEVEREERRORoccurs10:30:26org.jenkinsci.lib.envinject.EnvInjectException:java.lang.InterruptedException10:30:26 atorg.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvironmentVariablesNode(EnvironmentVariablesNodeLoader.java:77)10:30:26 atorg.jenkinsci.plugins.envinject.EnvInjectListener.loadEnvironmentVariablesNode(EnvInjectListener.java:81)10:30:26 atorg.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:39)10:30:26 athudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:575)10:30:26 athudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:481)10:30:26 athudson.model.Run.execute(Run.java:1689)10:30:26 athudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)10:30:26 athudson.model.ResourceController.execute(ResourceController.java:88)10:30:26 athudson.model.Executor.run(Executor.java:231)10:30:26Causedby:java.lang.InterruptedException10:30:26 atjava.lang.Object.wait(NativeMethod)10:30:26 athudson.remoting.Request.call(Request.java:146)10:30:26 athudson.remoting.Channel.call(Channel.java:722)10:30:26 athudson.FilePath.act(FilePath.java:1003)10:30:26 atorg.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvironmentVariablesNode(EnvironmentVariablesNodeLoader.java:44)10:30:26 ...8more10:30:26Archivingartifacts10:30:26ERROR:Publisherhudson.tasks.Mailerabortedduetoexception10:30:26hudson.remoting.ChannelClosedException:channelisalreadyclosed10:30:26 athudson.remoting.Channel.send(Channel.java:524)10:30:26 athudson.remoting.Request.call(Request.java:129)10:30:26 athudson.remoting.Channel.call(Channel.java:722)10:30:26 athudson.EnvVars.getRemote(EnvVars.java:404)10:30:26 athudson.model.Computer.getEnvironment(Computer.java:911)10:30:26 atjenkins.model.CoreEnvironmentContributor.buildEnvironmentFor(CoreEnvironmentContributor.java:29)10:30:26 athudson.model.Run.getEnvironment(Run.java:2202)10:30:26 athudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:873)10:30:26 athudson.tasks.Mailer.perform(Mailer.java:134)10:30:26 athudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)10:30:26 athudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)10:30:26
[JIRA] [slave-squatter] (JENKINS-24449) slave cleanup causes jobs to hang
Christian Goetze commented on JENKINS-24449 slave cleanup causes jobs to hang It appears that the slave crashes on the abort, and the only solution is to disconnect and reconnect the slave. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23120) FATAL: hudson.remoting.RequestAbortedException on Windows Slaves
Christian Goetze edited a comment on JENKINS-23120 FATAL: hudson.remoting.RequestAbortedException on Windows Slaves I am still blocked at 1.558 due to this bug. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23120) FATAL: hudson.remoting.RequestAbortedException on Windows Slaves
Christian Goetze edited a comment on JENKINS-23120 FATAL: hudson.remoting.RequestAbortedException on Windows Slaves I am still blocked at 1.558 due to this bug. Sadly, 1.558 has https://issues.jenkins-ci.org/browse/JENKINS-23120, but it's less common than this one... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23120) FATAL: hudson.remoting.RequestAbortedException on Windows Slaves
Christian Goetze commented on JENKINS-23120 FATAL: hudson.remoting.RequestAbortedException on Windows Slaves I am still blocked at 1.558 due to this bug. Sadly, 1.558 has https://issues.jenkins-ci.org/browse/JENKINS-22692, but it's less common than this one... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [plugin] (JENKINS-23719) Adding a system groovy conditional build step causes angry jenkins stacktrace
Christian Goetze created JENKINS-23719 Adding a system groovy conditional build step causes angry jenkins stacktrace Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: plugin Created: 08/Jul/14 10:22 PM Description: Caused by: java.lang.IllegalArgumentException: Failed to convert the scriptSource parameter of the constructor public hudson.plugins.groovy.SystemGroovy(hudson.plugins.groovy.ScriptSource,java.lang.String,java.lang.String) at org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:686) at org.kohsuke.stapler.RequestImpl.access$100(RequestImpl.java:81) at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:587) Environment: 1.558 Jenkins 1.15 Groovy Plugin 1.3.3 Conditional Buildstep Plugin Project: Jenkins Priority: Major Reporter: Christian Goetze This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git] (JENKINS-14575) SCM checkout retry count not working
Christian Goetze commented on JENKINS-14575 SCM checkout retry count not working Just to note that it isn't working for me either - using Jenkins 1.558, Git Client Plugin 1.9.1, Git Plugin 2.2.1. Sadly, we do get the occasional ssh connect failure, and we can't seem to find a way to fix it by itself, so retrying the checkout is the only way for us to get more reliable builds. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23120) FATAL: hudson.remoting.RequestAbortedException on Windows Slaves
Christian Goetze commented on JENKINS-23120 FATAL: hudson.remoting.RequestAbortedException on Windows Slaves This stacktrace appeared in the console log right in the middle of a running build. Another observable symptom is that all the windows slave appear to disconnect, then reconnect. The slaves don't actually crash, it appears. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [windows-slaves] (JENKINS-22692) Jenkins Windows-Slave throwing exception on shutdown causes connection reset issues
Christian Goetze commented on JENKINS-22692 Jenkins Windows-Slave throwing exception on shutdown causes connection reset issues I'm observing the same problem. I now run a groovy script to disconnect the slave first prior to rebooting the slave, but even then it somehow gets itself into that state. When I disconnect manually, then reboot, then it appears to work fine. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [windows-slaves] (JENKINS-22692) Jenkins Windows-Slave throwing exception on shutdown causes connection reset issues
Christian Goetze edited a comment on JENKINS-22692 Jenkins Windows-Slave throwing exception on shutdown causes connection reset issues I'm observing the same problem. I now run a groovy script to disconnect the slave first prior to rebooting the slave, but even then it somehow gets itself into that state. When I disconnect manually, then reboot, then it appears to work fine. Interestingly, this issue only started occurring on windows 7 in headless mode. I have some older slaves still running XP where this does not occur. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [windows-slaves] (JENKINS-22692) Jenkins Windows-Slave throwing exception on shutdown causes connection reset issues
Christian Goetze commented on JENKINS-22692 Jenkins Windows-Slave throwing exception on shutdown causes connection reset issues So it appears that in my case, the problem is that the slave manages to reconnect prior to the reboot. So the way I need to code this is: First kill the slave service (or power off the VM, or whatever works), making sure the slave is dead. Then tell the master the slave is disconnected Then do whatever operations you want on the slave machine and restart the slave service when ready Then the master will allow the connection... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23120) FATAL: hudson.remoting.RequestAbortedException on Windows Slaves
Christian Goetze created JENKINS-23120 FATAL: hudson.remoting.RequestAbortedException on Windows Slaves Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 21/May/14 5:13 AM Description: 21:59:46 FATAL: hudson.remoting.RequestAbortedException: java.nio.channels.AsynchronousCloseException 21:59:46 hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.nio.channels.AsynchronousCloseException 21:59:46 at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) 21:59:46 at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) 21:59:46 at hudson.remoting.Request.call(Request.java:174) 21:59:46 at hudson.remoting.Channel.call(Channel.java:739) 21:59:46 at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168) 21:59:46 at com.sun.proxy.$Proxy56.join(Unknown Source) 21:59:46 at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:951) 21:59:46 at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:137) 21:59:46 at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:97) 21:59:46 at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) 21:59:46 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 21:59:46 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:745) 21:59:46 at hudson.model.Build$BuildExecution.build(Build.java:198) 21:59:46 at hudson.model.Build$BuildExecution.doRun(Build.java:159) 21:59:46 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:518) 21:59:46 at hudson.model.Run.execute(Run.java:1706) 21:59:46 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 21:59:46 at hudson.model.ResourceController.execute(ResourceController.java:88) 21:59:46 at hudson.model.Executor.run(Executor.java:231) 21:59:46 Caused by: hudson.remoting.RequestAbortedException: java.nio.channels.AsynchronousCloseException 21:59:46 at hudson.remoting.Request.abort(Request.java:299) 21:59:46 at hudson.remoting.Channel.terminate(Channel.java:802) 21:59:46 at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) 21:59:46 Caused by: java.nio.channels.AsynchronousCloseException 21:59:46 at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:205) 21:59:46 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:412) 21:59:46 at hudson.remoting.SocketChannelStream$1.read(SocketChannelStream.java:33) 21:59:46 at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:65) 21:59:46 at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109) 21:59:46 at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) 21:59:46 at java.io.InputStream.read(InputStream.java:101) 21:59:46 at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:81) 21:59:46 at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:82) 21:59:46 at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2293) 21:59:46 at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2586) 21:59:46 at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2596) 21:59:46 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1318) 21:59:46 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) 21:59:46 at hudson.remoting.Command.readFrom(Command.java:92) 21:59:46 at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:70) 21:59:46 at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Project: Jenkins Priority: Major
[JIRA] [core] (JENKINS-22853) SEVERE: Trying to unexport an object that's already unexported
Christian Goetze commented on JENKINS-22853 SEVERE: Trying to unexport an object thats already unexported I just attempted to upgrade to 1.564, but had to revert again - JENKINS-23120 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git] (JENKINS-22009) Git Polling Keeps Detecting Changes When Variables in refspec
Christian Goetze
created JENKINS-22009
Git Polling Keeps Detecting Changes When Variables in refspec
Issue Type:
Bug
Assignee:
Nicolas De Loof
Components:
git
Created:
02/Mar/14 8:25 PM
Description:
I have a job where the git refspec and branch are set to +refs/heads/${branch}:refs/remotes/origin/${branch} and the branch is set to ${branch}.
With that configuration, the SCM polling keeps triggering new builds from the same change.
If I replace the variables with their values, the SCM polling works correctly.
Project:
Jenkins
Priority:
Major
Reporter:
Christian Goetze
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [git] (JENKINS-21000) Git plugin should ignore failure to retrieve previous build ref
Christian Goetze created JENKINS-21000 Git plugin should ignore failure to retrieve previous build ref Issue Type: Bug Assignee: Nicolas De Loof Components: git Created: 12/Dec/13 10:33 PM Description: Jenkins appears to obsess about knowing what the previous build's ref was. If that ref is unavailable in the current clone, the build fails. This is prevalent in builds triggered by gerrit, since they will often be from random refs in the history, and not necessarily in any meaningful order. It would be nice if there was a way to tell Jenkins to not even try to determine what the previous build was, but meanwhile it would just help if the build didn't fall over just because the previous build is unavailable. Project: Jenkins Priority: Major Reporter: Christian Goetze This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [git] (JENKINS-21001) Git plugin should use git init + git fetch instead of git clone
Christian Goetze
created JENKINS-21001
Git plugin should use git init + git fetch instead of git clone
Issue Type:
Bug
Assignee:
Nicolas De Loof
Components:
git
Created:
13/Dec/13 12:43 AM
Description:
It appears that whenever I use a gerrit refspec, I get into trouble when trying to clone a new workspace:
16:28:57 Started by upstream project "gerrit" build number 141
16:28:57 originally caused by:
16:28:57 Started by user Christian Goetze
16:28:57 [EnvInject] - Loading node environment variables.
16:28:57 Building remotely on centos5-x64-bld-slave-50 in workspace /build/jenkins/workspace/test-against-installed-controller
16:28:57 Cloning the remote Git repository
16:28:57 Cloning repository ssh://jenki...@gerrit.corp.appdynamics.com:29418/codebase.git
16:28:57 git --version
16:28:57 git version 1.8.2.1
16:29:59 FATAL: Command "rev-parse c848ac1d1a98e400b31e4c28425f7e32624e225b^{commit}" returned status code 128:
16:29:59 stdout: c848ac1d1a98e400b31e4c28425f7e32624e225b^{commit}
I think "the pros" use a git init followed by a git fetch to obtain the exact desired refspec. See http://stackoverflow.com/questions/4811434/clone-only-one-branch/14930421#14930421
Project:
Jenkins
Priority:
Major
Reporter:
Christian Goetze
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [git] (JENKINS-21001) Git plugin should use git init + git fetch instead of git clone
Christian Goetze
updated JENKINS-21001
Git plugin should use git init + git fetch instead of git clone
Change By:
Christian Goetze
(13/Dec/13 12:44 AM)
Description:
ItappearsthatwheneverIuseagerritrefspec,Igetintotroublewhentryingtocloneanewworkspace:{noformat}16:28:57Startedbyupstreamprojectgerritbuildnumber14116:28:57originallycausedby:16:28:57StartedbyuserChristianGoetze16:28:57[EnvInject]-Loadingnodeenvironmentvariables.16:28:57Buildingremotelyon
centos5-x64-bld-slave-50
XX
inworkspace/build/jenkins/workspace/
test-against-installed-controller
Y
16:28:57CloningtheremoteGitrepository16:28:57Cloningrepositoryssh://jenkins4@gerrit.
corp.appdynamics.com
Z
:29418/codebase.git16:28:57git--version16:28:57gitversion1.8.2.116:29:59FATAL:Commandrev-parsec848ac1d1a98e400b31e4c28425f7e32624e225b^{commit}returnedstatuscode128:16:29:59stdout:c848ac1d1a98e400b31e4c28425f7e32624e225b^{commit}{noformat}Ithinktheprosuseagitinitfollowedbyagitfetchtoobtaintheexactdesiredrefspec.Seehttp://stackoverflow.com/questions/4811434/clone-only-one-branch/14930421#14930421
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [git] (JENKINS-21001) Git plugin should use git init + git fetch instead of git clone
Christian Goetze commented on JENKINS-21001 Git plugin should use git init + git fetch instead of git clone Or use a git fetch after a git clone, just as if the workspace already existed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [plugin] (JENKINS-20846) MultiJobRunner has NullPointerException on unstable sub-builds
Christian Goetze created JENKINS-20846 MultiJobRunner has NullPointerException on unstable sub-builds Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: plugin Created: 03/Dec/13 1:08 AM Description: 16:47:29 java.lang.NullPointerException 16:47:29 at hudson.model.queue.FutureImpl.cancel(FutureImpl.java:78) 16:47:29 at com.tikal.jenkins.plugins.multijob.MultiJobBuilder.perform(MultiJobBuilder.java:162) 16:47:29 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 16:47:29 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:785) 16:47:29 at hudson.model.Build$BuildExecution.build(Build.java:199) 16:47:29 at hudson.model.Build$BuildExecution.doRun(Build.java:160) 16:47:29 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:566) 16:47:29 at com.tikal.jenkins.plugins.multijob.MultiJobBuild$MultiJobRunnerImpl.run(MultiJobBuild.java:70) 16:47:29 at hudson.model.Run.execute(Run.java:1677) 16:47:29 at hudson.model.Run.run(Run.java:1624) 16:47:29 at com.tikal.jenkins.plugins.multijob.MultiJobBuild.run(MultiJobBuild.java:63) 16:47:29 at hudson.model.ResourceController.execute(ResourceController.java:88) 16:47:29 at hudson.model.Executor.run(Executor.java:230) Project: Jenkins Priority: Major Reporter: Christian Goetze This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [configure-job-column] (JENKINS-20823) Stack Trace when Configuring a task with Label Factory
Christian Goetze created JENKINS-20823 Stack Trace when Configuring a task with Label Factory Issue Type: Bug Affects Versions: current Assignee: jieryn Components: configure-job-column Created: 29/Nov/13 5:34 PM Description: The following config.xml generates a stack trace: noformat ?xml version='1.0' encoding='UTF-8'? project actions/ descriptionJob to run ansible on all centos machines/description logRotator class="hudson.tasks.LogRotator" daysToKeep10/daysToKeep numToKeep-1/numToKeep artifactDaysToKeep-1/artifactDaysToKeep artifactNumToKeep-1/artifactNumToKeep /logRotator keepDependenciesfalse/keepDependencies properties hudson.model.ParametersDefinitionProperty parameterDefinitions org.jvnet.jenkins.plugins.nodelabelparameter.NodeParameterDefinition plugin="nodelabelparameter@1.4" nameLINUX-SLAVE/name description/description allowedSlaves stringALL (no restriction)/string /allowedSlaves defaultSlaves/ triggerIfResultallowMultiSelectionForConcurrentBuilds/triggerIfResult allowMultiNodeSelectiontrue/allowMultiNodeSelection triggerConcurrentBuildstrue/triggerConcurrentBuilds ignoreOfflineNodesfalse/ignoreOfflineNodes /org.jvnet.jenkins.plugins.nodelabelparameter.NodeParameterDefinition /parameterDefinitions /hudson.model.ParametersDefinitionProperty /properties scm class="hudson.plugins.git.GitSCM" plugin="git@1.5.0" configVersion2/configVersion userRemoteConfigs hudson.plugins.git.UserRemoteConfig name/name refspec/refspec urlssh://jenkins4@gerrit.my-company:29418/codebase.git/url /hudson.plugins.git.UserRemoteConfig /userRemoteConfigs branches hudson.plugins.git.BranchSpec namemaster/name /hudson.plugins.git.BranchSpec /branches disableSubmodulesfalse/disableSubmodules recursiveSubmodulesfalse/recursiveSubmodules doGenerateSubmoduleConfigurationsfalse/doGenerateSubmoduleConfigurations authorOrCommitterfalse/authorOrCommitter cleantrue/clean wipeOutWorkspacefalse/wipeOutWorkspace pruneBranchesfalse/pruneBranches remotePollfalse/remotePoll ignoreNotifyCommitfalse/ignoreNotifyCommit useShallowClonefalse/useShallowClone buildChooser class="hudson.plugins.git.util.DefaultBuildChooser"/ gitToolDefault/gitTool submoduleCfg class="list"/ relativeTargetDir/relativeTargetDir reference/build/jenkins/codebase.git/reference excludedRegions/excludedRegions excludedUsers/excludedUsers gitConfigName/gitConfigName gitConfigEmail/gitConfigEmail skipTagfalse/skipTag includedRegions/includedRegions scmName/scmName /scm assignedNodeadmin-linux/assignedNode canRoamfalse/canRoam disabledfalse/disabled blockBuildWhenDownstreamBuildingfalse/blockBuildWhenDownstreamBuilding blockBuildWhenUpstreamBuildingfalse/blockBuildWhenUpstreamBuilding jdkJDK6/jdk triggers/ concurrentBuildtrue/concurrentBuild builders hudson.tasks.Shell command/bin/sh -x jenkins/admin-slaves-linux.sh/command /hudson.tasks.Shell /builders publishers/ buildWrappers hudson.plugins.timestamper.TimestamperBuildWrapper plugin="timestamper@1.5.7"/ /buildWrappers /project noformat Stack Trace: noformat javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/lib/jenkins/plugins/nodelabelparameter/WEB-INF/lib/classes.jar!/org/jvnet/jenkins/plugins/nodelabelparameter/NodeParameterDefinition/config.jelly:59:153: j:invokeStatic method getSlaveNamesForSelection threw exception: Comparison method violates its general contract! at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248) at
[JIRA] [configure-job-column] (JENKINS-20823) Stack Trace when Configuring a task with Label Factory
Christian Goetze
updated JENKINS-20823
Stack Trace when Configuring a task with Label Factory
Change By:
Christian Goetze
(29/Nov/13 5:35 PM)
Description:
Thefollowingconfig.xmlgeneratesastacktrace:{
{
noformat}
}
?xmlversion=1.0encoding=UTF-8?projectactions/descriptionJobtorunansibleonallcentosmachines/descriptionlogRotatorclass=hudson.tasks.LogRotatordaysToKeep10/daysToKeepnumToKeep-1/numToKeepartifactDaysToKeep-1/artifactDaysToKeepartifactNumToKeep-1/artifactNumToKeep/logRotatorkeepDependenciesfalse/keepDependenciespropertieshudson.model.ParametersDefinitionPropertyparameterDefinitionsorg.jvnet.jenkins.plugins.nodelabelparameter.NodeParameterDefinitionplugin=nodelabelparameter@1.4nameLINUX-SLAVE/namedescription/descriptionallowedSlavesstringALL(norestriction)/string/allowedSlavesdefaultSlaves/triggerIfResultallowMultiSelectionForConcurrentBuilds/triggerIfResultallowMultiNodeSelectiontrue/allowMultiNodeSelectiontriggerConcurrentBuildstrue/triggerConcurrentBuildsignoreOfflineNodesfalse/ignoreOfflineNodes/org.jvnet.jenkins.plugins.nodelabelparameter.NodeParameterDefinition/parameterDefinitions/hudson.model.ParametersDefinitionProperty/propertiesscmclass=hudson.plugins.git.GitSCMplugin=git@1.5.0configVersion2/configVersionuserRemoteConfigshudson.plugins.git.UserRemoteConfigname/namerefspec/refspecurlssh://jenkins4@gerrit.my-company:29418/codebase.git/url/hudson.plugins.git.UserRemoteConfig/userRemoteConfigsbrancheshudson.plugins.git.BranchSpecnamemaster/name/hudson.plugins.git.BranchSpec/branchesdisableSubmodulesfalse/disableSubmodulesrecursiveSubmodulesfalse/recursiveSubmodulesdoGenerateSubmoduleConfigurationsfalse/doGenerateSubmoduleConfigurationsauthorOrCommitterfalse/authorOrCommittercleantrue/cleanwipeOutWorkspacefalse/wipeOutWorkspacepruneBranchesfalse/pruneBranchesremotePollfalse/remotePollignoreNotifyCommitfalse/ignoreNotifyCommituseShallowClonefalse/useShallowClonebuildChooserclass=hudson.plugins.git.util.DefaultBuildChooser/gitToolDefault/gitToolsubmoduleCfgclass=list/relativeTargetDir/relativeTargetDirreference/build/jenkins/codebase.git/referenceexcludedRegions/excludedRegionsexcludedUsers/excludedUsersgitConfigName/gitConfigNamegitConfigEmail/gitConfigEmailskipTagfalse/skipTagincludedRegions/includedRegionsscmName/scmName/scmassignedNodeadmin-linux/assignedNodecanRoamfalse/canRoamdisabledfalse/disabledblockBuildWhenDownstreamBuildingfalse/blockBuildWhenDownstreamBuildingblockBuildWhenUpstreamBuildingfalse/blockBuildWhenUpstreamBuildingjdkJDK6/jdktriggers/concurrentBuildtrue/concurrentBuildbuildershudson.tasks.Shellcommand/bin/sh-xjenkins/admin-slaves-linux.sh/command/hudson.tasks.Shell/builderspublishers/buildWrappershudson.plugins.timestamper.TimestamperBuildWrapperplugin=timestamper@1.5.7//buildWrappers/project{
{
noformat}
}
StackTrace:{
{
noformat}
}
javax.servlet.ServletException:org.apache.commons.jelly.JellyTagException:jar:file:/var/lib/jenkins/plugins/nodelabelparameter/WEB-INF/lib/classes.jar!/org/jvnet/jenkins/plugins/nodelabelparameter/NodeParameterDefinition/config.jelly:59:153:lt;j:invokeStaticgt;methodgetSlaveNamesForSelectionthrewexception:Comparisonmethodviolatesitsgeneralcontract! atorg.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:858) atorg.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248) atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:858) atorg.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248) atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:858) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:631) atorg.kohsuke.stapler.Stapler.service(Stapler.java:225) atjavax.servlet.http.HttpServlet.service(HttpServlet.java:848) atorg.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) atorg.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494)
[JIRA] [build-timeout] (JENKINS-20526) Allow timouts to be set via parameter
Christian Goetze
created JENKINS-20526
Allow timouts to be set via parameter
Issue Type:
New Feature
Assignee:
Kohsuke Kawaguchi
Components:
build-timeout
Created:
11/Nov/13 7:26 PM
Description:
Currently, the timeout field only allows integers. It would be nice if one could put in ${xxx} style parameters which can be set centrally for all build tasks.
Project:
Jenkins
Priority:
Major
Reporter:
Christian Goetze
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
