Long delays in multibranch pipelines "Seen X remote branches"
Hi, We often see long delays during multibranch pipeline builds. The job shows Branch indexing > git rev-parse --is-inside-work-tree # timeout=10 Setting origin to g...@github.com:foo/bar.git > git config remote.origin.url g...@github.com:foo/bar.git # timeout=10 Fetching origin... Fetching upstream changes from origin > git --version # timeout=10 using GIT_SSH to set credentials > git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/* Seen branch in repository origin/branch-1 Seen branch in repository origin/branch-2 ... Seen branch in repository origin/branch-559 Seen 559 remote branches There is then a long delay before it shows Obtained proj/Jenkinsfile from 61b5c00e80eaf221bb354e07ccfb3f56cb657484 Looking at the processes on the Jenkins master machine, it seems that there are just a couple of git processes (at 100% CPU) trying to checkout the different branches and get the appropriate Jenkinsfile. Does anyone know why takes so long (the master has more than enough resources)? Or how I can improve this? I'm using Jenkins ver. 2.89.4 Thanks, David -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5e68765d-b6b9-472d-9de5-b0a80e161873%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
jclouds-plugin not removing last slave
We're using the JClouds plugin with cloudstack and a retention time of 240 minutes. Slaves are spinning up on demand and are generally brought offline as expected. There is a problem with the last slave; even when it is unused for more than 240 minutes, it is never brought offline. It is always the longest living slave that is kept. Has anyone had the same experience? Any ideas on getting this working correctly? Jenkins 1.642.1 jclouds-plugin 2.9 Thanks, David -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b37913bc-c9dc-4fe8-937c-868e1d226a6c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [workflow] email-ext step fails in freestyle project triggered by buildJob
https://issues.jenkins-ci.org/browse/JENKINS-29970 - David On Thursday, August 13, 2015 at 12:11:16 AM UTC+3, Jesse Glick wrote: On Wednesday, July 29, 2015 at 9:23:01 AM UTC-4, David Resnick wrote: java.lang.ClassCastException: org.jenkinsci.plugins.workflow.job.WorkflowJob cannot be cast to hudson.model.AbstractProject at hudson.plugins.emailext.plugins.recipients.UpstreamComitterRecipientProvider.addRecipients(UpstreamComitterRecipientProvider.java:40) Email Ext is not currently supported *from* a Workflow project, and that is a deep topic. But it is clearly a straightforward bug in that plugin that it does a blind cast of the *upstream* project. If it cannot handle an arbitrary `Job` here, it should print a warning and move on. File it please, label `workflow`. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9546497d-8001-43d8-8e84-c9baeca0ff4a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Approve workflow script from Job DSL plugin
I've set the script to be sandboxed in the Job DSL script, though it looks link only a marginal improvement because of the need to approve missing method signatures. What would the Job DSL plugin need to do to automatically approve the non-sandboxed script it sets in a job? As you mention, security here is already being by-passed when the Job DSL plugin is in use. - David On Thursday, August 13, 2015 at 12:05:14 AM UTC+3, Jesse Glick wrote: On Tuesday, July 21, 2015 at 4:17:51 PM UTC-4, David Resnick wrote: How can I have the workflow job script updated via Job DSL without having to approve the script each time it changes? If the Job DSL plugin supports setting sandbox=true here, use that. However it would be a nice enhancement for the Job DSL integration to automatically approve a flow definition with sandbox=false that it creates. (Job DSL builds have unrestricted access to Jenkins so anything created that way can be assumed to be from a superuser. I am not even sure how you would secure a Jenkins installation containing this plugin, unless you are using only basic security levels like “any logged-in user”.) -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0e341cce-c18e-4779-9b94-543aea0f4b89%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[workflow] email-ext step fails in freestyle project triggered by buildJob
I have a freestyle job that fails to run the post-build extended email step when it is triggered by a workflow buildJob construct. The error message: ERROR: Could not send email as a part of the post-build publishers. java.lang.ClassCastException: org.jenkinsci.plugins.workflow.job.WorkflowJob cannot be cast to hudson.model.AbstractProject at hudson.plugins.emailext.plugins.recipients.UpstreamComitterRecipientProvider.addRecipients(UpstreamComitterRecipientProvider.java:40) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:578) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:306) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:297) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:244) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.cleanUp(Build.java:193) at hudson.model.Run.execute(Run.java:1788) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:374) It seems that it might be able to succeed if I remove some of the categories I chose to send to, though I have not yet experimented with this. Is there a known workaround for this problem? Would it be helpful for me to open a bug for this? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/cbf83da3-943d-4a91-a8e2-8dd389175c20%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [workflow] email-ext step fails in freestyle project triggered by buildJob
Is there any plan to bridge this divide? I notice that it pops up fairly often whenever the workflow plugin is in the picture. - David On Wednesday, July 29, 2015 at 4:26:36 PM UTC+3, slide wrote: This is a known incompatibility between workflow and email-ext. Email-ext expects projects to be based on AbstractProject and Workflow is not. On Wed, Jul 29, 2015 at 6:23 AM David Resnick abun...@gmail.com javascript: wrote: I have a freestyle job that fails to run the post-build extended email step when it is triggered by a workflow buildJob construct. The error message: ERROR: Could not send email as a part of the post-build publishers. java.lang.ClassCastException: org.jenkinsci.plugins.workflow.job.WorkflowJob cannot be cast to hudson.model.AbstractProject at hudson.plugins.emailext.plugins.recipients.UpstreamComitterRecipientProvider.addRecipients(UpstreamComitterRecipientProvider.java:40) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:578) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:306) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:297) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:244) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.cleanUp(Build.java:193) at hudson.model.Run.execute(Run.java:1788) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:374) It seems that it might be able to succeed if I remove some of the categories I chose to send to, though I have not yet experimented with this. Is there a known workaround for this problem? Would it be helpful for me to open a bug for this? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/cbf83da3-943d-4a91-a8e2-8dd389175c20%40googlegroups.com https://groups.google.com/d/msgid/jenkinsci-users/cbf83da3-943d-4a91-a8e2-8dd389175c20%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/420b8dfb-cfe8-4eba-a88c-85a669d237e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Approve workflow script from Job DSL plugin
I have a workflow script that I set in the workflow job Groovy CPS DSL
textbox via Job DSL. The problem is that though security on the server is
set to logged in users can do anything, apparently the script is not set
as Jenkins administrator.
How can I have the workflow job script updated via Job DSL without having
to approve the script each time it changes?
This is the general layout of the Job DSL:
def flow = '''
node {
git url: 'ssh://g...@git.com/repo.git'
}
'''
workflowJob('job1') {
triggers {
scm('# triggered by post-commit hook')
}
definition {
cps {
script(flow)
}
}
}
Jenkins is 1.609.1, workflow 1.8, job dsl 1.35.
Thanks,
David
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/0a562bd7-e5ef-4b5b-b1c6-998f24cb4770%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Failing to iterate list with workflow
Thanks!
This is indeed another case
of https://issues.jenkins-ci.org/browse/JENKINS-27421
Here is a working snippet:
def branches = [:]
def jobs = [ 'job-1' ]
def jobName
for (int i = 0; i jobs.size(); i++) {
jobName = jobs[i]
// jobName must be used inside the build job closure
branches[jobName] = { build job: jobName }
}
parallel branches
- David
On Wednesday, July 15, 2015 at 12:41:06 PM UTC+3, Arek Skalski wrote:
Try to use classic:
for(int i = 0 ; i jobs.length(); ++i) {...}
W dniu wtorek, 14 lipca 2015 21:40:08 UTC+2 użytkownik David Resnick
napisał:
I'm trying create jobs to run in parallel in a workflow with this script:
def branches = [:]
def jobs = [ 'job-1' ]
for (job in jobs) {
branches[job] = { build job: job }
}
parallel branches
This fails with the below (though it doesn't fail when 'parallel
branches' is commented out).
How can this be done?
Thanks,
David
Running: Execute sub-workflows in parallel : Start
[job-1] Running: Parallel branch: job-1
[job-1] Running: Build a Job
[job-1] Starting building project: job-1
Running: Execute sub-workflows in parallel : Body : End
Running: End of Workflow
java.io.NotSerializableException: java.util.ArrayList$Itr
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:860)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:967)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:65)
at
org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:56)
at
org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:50)
at
org.jboss.marshalling.river.RiverObjectOutputStream.writeObjectOverride(RiverObjectOutputStream.java:179)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
at java.util.HashMap.writeObject(HashMap.java:1354)
at sun.reflect.GeneratedMethodAccessor144.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:271)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:976)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)
at
org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)
at
org.jenkinsci.plugins.workflow.support.pickles.serialization.RiverWriter.writeObject(RiverWriter.java:133
Failing to iterate list with workflow
I'm trying create jobs to run in parallel in a workflow with this script:
def branches = [:]
def jobs = [ 'job-1' ]
for (job in jobs) {
branches[job] = { build job: job }
}
parallel branches
This fails with the below (though it doesn't fail when 'parallel branches'
is commented out).
How can this be done?
Thanks,
David
Running: Execute sub-workflows in parallel : Start
[job-1] Running: Parallel branch: job-1
[job-1] Running: Build a Job
[job-1] Starting building project: job-1
Running: Execute sub-workflows in parallel : Body : End
Running: End of Workflow
java.io.NotSerializableException: java.util.ArrayList$Itr
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:860)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:967)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:65)
at
org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:56)
at
org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:50)
at
org.jboss.marshalling.river.RiverObjectOutputStream.writeObjectOverride(RiverObjectOutputStream.java:179)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
at java.util.HashMap.internalWriteEntries(HashMap.java:1777)
at java.util.HashMap.writeObject(HashMap.java:1354)
at sun.reflect.GeneratedMethodAccessor144.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:271)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:976)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988)
at
org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854)
at
org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)
at
org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)
at
org.jenkinsci.plugins.workflow.support.pickles.serialization.RiverWriter.writeObject(RiverWriter.java:133)
at
org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.saveProgram(CpsThreadGroup.java:344)
at
org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.saveProgram(CpsThreadGroup.java:328)
at
org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:303)
at
org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$000(CpsThreadGroup.java:71)
at
org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:180)
at
Re: Job without trigger building constantly because of SCM change
Our problem went away, unfortunately we don't know why. - David On Saturday, June 27, 2015 at 1:10:40 AM UTC+3, tfasz wrote: Hi David - wondering if you resolved this issue. I'm seeing something very similar - a job that gets into a build loop. When I manually hit the Build Now button I immediately see 2 instances of the jobs scheduled with the second one pending completion of the first. Then when the second one starts it triggers a third, etc. The first instance is Started by user and the subsequent ones are Started by an SCM change. Job details: - Maven job type - Git repo - trigger on SCM poll - Git option to check out to specific local branch specified The build #1 appears to run fine but then once a check-in happens to the repo the next triggered (or manually run) build starts looping. Jenkins 1.609.1 Git plugin 2.3.5 Maven plugin 2.10 On Wednesday, May 20, 2015 at 10:40:23 PM UTC-7, David Resnick wrote: Unfortunately, I don't have a lot to add to the subject. The job has SCM but no triggers -- it is triggered using the Parameterized Trigger Plugin. Yesterday we noticed that it was running continuously (using default parameters), restarting as soon as it finishes the previous build. The builds indicate that they were started by SCM change, but that there were no changes. There have been no new commits in the (git) SCM. Disabling and then enabling the job stopped it from building, but once it was triggered again (manually) it once again built continuously until disabled. The logs don't show anything out of the ordinary, just that the job completes successfully: May 20, 2015 12:27:10 PM hudson.model.Run execute INFO: Update Machine #5372 main build action completed: SUCCESS Jenkins is 1.608 with a lot of plugins. There have not been any plugins installed or upgraded recently that might be the trigger to this problem. Any ideas or suggestions? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b46ecd0b-c5f9-4be7-9575-53ba8db4d152%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Jenkins master automatic setup
I'm very pleased with using the Job DSL plugin to keep job configuration in SCM, both for setting up a new Jenkins instance as well as for keeping track of job changes over time. Does anyone have a similar solution for setting up and maintaining a Jenkins master? This would include such settings as tool installations, email defaults and, most important, slave definitions. I'm hoping to find a groovy or DSL based solution; anything that is cleaner than checking in the master config.xml. I'd really appreciate hearing what other people have worked out. Thanks! - David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/94e52e15-dab9-475e-bf0d-9c4110c24658%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins master automatic setup
Thanks for sharing your setup. I'm setting up a new server and am going all docker as well -- master and slaves, with the slaves using the swarm plugin so that they find the master instead of the other way around. As you said, all the tools are already set up in containers. I'd really like to be able to do the final step via some kind of script or preparation in advance that doesn't include going from a previously set up master persisted in a config.xml file. - David On Sunday, June 28, 2015 at 10:12:32 PM UTC+3, tfasz wrote: We have been using the Job DSL plugin as well and are very happy with it. We probably generate ~90% of our jobs using it with the rest created by hand. Our Jenkins master and slaves are all setup running in Docker containers. The master has the Jenkins home directory mounted from a directory on the host, so it persists across Docker container restarts. The containers are started from Docker images built with a Dockerfile, so all of the software install (Git, Java, Ant, Maven, etc) and initial configuration (ssh keys, etc) is in these Dockerfiles. Once the Jenkins master is started up, there is some manual configuration through Jenkins to setup slaves, settings, etc. We then have a backup job run daily to do a thin backup of the Jenkins home directory to S3. Setting up a new master from scratch takes about 15 minutes and requires downloading the backup from S3 and spinning up the Docker container. Spinning up a slave is as simple as starting a Docker container with the slave image somewhere and then hooking it up to the master. We are also using Docker as the basis for all of our test environments. After a build is complete in Jenkins, downstream jobs spin up a set of Docker containers and deploy the built software to those containers. All in all, we have been pretty happy with the setup and Docker has been getting more stable and mature over the past year. Looking forward to their new multi-host networking coming soon - will allow us to spin up test containers across a fleet of machines instead of our one really large instance we use now. On Sun, Jun 28, 2015 at 1:13 AM, David Resnick abun...@gmail.com javascript: wrote: I'm very pleased with using the Job DSL plugin to keep job configuration in SCM, both for setting up a new Jenkins instance as well as for keeping track of job changes over time. Does anyone have a similar solution for setting up and maintaining a Jenkins master? This would include such settings as tool installations, email defaults and, most important, slave definitions. I'm hoping to find a groovy or DSL based solution; anything that is cleaner than checking in the master config.xml. I'd really appreciate hearing what other people have worked out. Thanks! - David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/94e52e15-dab9-475e-bf0d-9c4110c24658%40googlegroups.com https://groups.google.com/d/msgid/jenkinsci-users/94e52e15-dab9-475e-bf0d-9c4110c24658%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/a8a3123a-4cfb-403f-9808-d7213a6ca32b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Job without trigger building constantly because of SCM change
Unfortunately, I don't have a lot to add to the subject. The job has SCM but no triggers -- it is triggered using the Parameterized Trigger Plugin. Yesterday we noticed that it was running continuously (using default parameters), restarting as soon as it finishes the previous build. The builds indicate that they were started by SCM change, but that there were no changes. There have been no new commits in the (git) SCM. Disabling and then enabling the job stopped it from building, but once it was triggered again (manually) it once again built continuously until disabled. The logs don't show anything out of the ordinary, just that the job completes successfully: May 20, 2015 12:27:10 PM hudson.model.Run execute INFO: Update Machine #5372 main build action completed: SUCCESS Jenkins is 1.608 with a lot of plugins. There have not been any plugins installed or upgraded recently that might be the trigger to this problem. Any ideas or suggestions? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b86cd641-0f67-4cd8-8d18-406f861f85f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins burning devil w/Stack trace--how to recover???
It sounds like you're hitting the same problem I have: https://issues.jenkins-ci.org/browse/JENKINS-27537 - David On Saturday, March 28, 2015 at 12:37:48 AM UTC+3, Steve K wrote: Since Jenkins was operational--just not usable for most users--I decided to try downgrading the plugins that I upgraded. The first plugin I downgraded was Build Pipeline Plugin. I took that from 1.4.7 back down to 1.4.4 That did the trick! Can't believe it. I feel lucky. I might even go buy a lottery ticket! Actually, since it was the presentation of the web pages that was most affected, the Build Pipeline Plugin seemed to be the most closely associated. BTW. The server is Jenkins ver 1.580.1 I'd still be interested in hearing what you would have done if downgrading the plugin had not worked. If something like this happens again, I'll take James Nord's advice and include the stack trace. Thanks. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/acace209-f1fc-488c-b52c-1a5a10d949fd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Failure with Jenkins 1.602 and build pipeline plugin 1.4.6
I still have the same problem with build-pipeline plugin 1.4.7 and Jenkins 1.605. I've opened a bug to track this: https://issues.jenkins-ci.org/browse/JENKINS-27537 - David On Monday, March 16, 2015 at 5:57:24 PM UTC+2, rup...@einserver.de wrote: The same happens for me too with Jenkins in version 1.596.1 and Build Pipeline in 1.4.6. As for you, downgrading to 1.4.5. temporarily solves the issue. Regards, Andreas Am Sonntag, 15. März 2015 16:32:44 UTC+1 schrieb David Resnick: I upgraded Jenkins and a number of plugins and got the below exception in Jenkins list view. After downgrading build pipeline plugin to 1.4.5, the problem ceased. Has anyone else encountered this problem? Does anyone have 1.602 and 1.4.6 working together? Thanks, David Stack trace javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.602.jar!/hudson/model/View/index.jelly:42:43: st:include org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.602.jar!/lib/hudson/projectView.jelly:67:24: d:invokeBody java.lang.ClassCastException at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:117) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:735) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) at com.smartcodeltd.jenkinsci.plugin.assetbundler.filters.LessCSS.doFilter(LessCSS.java:46) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:95) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:198) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:176) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:85) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:99) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2
Failure with Jenkins 1.602 and build pipeline plugin 1.4.6
I upgraded Jenkins and a number of plugins and got the below exception in Jenkins list view. After downgrading build pipeline plugin to 1.4.5, the problem ceased. Has anyone else encountered this problem? Does anyone have 1.602 and 1.4.6 working together? Thanks, David Stack trace javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.602.jar!/hudson/model/View/index.jelly:42:43: st:include org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.602.jar!/lib/hudson/projectView.jelly:67:24: d:invokeBody java.lang.ClassCastException at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:117) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:735) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) at com.smartcodeltd.jenkinsci.plugin.assetbundler.filters.LessCSS.doFilter(LessCSS.java:46) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:95) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:198) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:176) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:85) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:99) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at
Re: Connection Refused error when running Sbt Tests in Jenkins but it works fine in local machine
I would recommend logging in to where Jenkins is trying to run sbt, cd-ing
to the workspace and trying to run sbt yourself from the command line. Take
Jenkins out of the loop. Maybe you might have a proxy issue on the
slave/master where you are running sbt.
- David
On Monday, December 8, 2014 6:09:08 PM UTC+2, Vijaykumar Gundavarapu wrote:
Hi,
I have a simple Jenkins job which executes some Sbt tests in scala/akka
and it tries to download Mongo flapdoodle to execute a test.
The tests works fine in local machine but I get connection refused error
when it runs in Jenkins.
Download Version{2.4.10}:Linux:B64 START
Dec 05, 2014 5:42:19 PM de.flapdoodle.embed.process.runtime.Starter prepare
SEVERE: prepare executable
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at sun.net.NetworkClient.doConnect(NetworkClient.java:175)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.init(HttpClient.java:211)
at sun.net.www.http.HttpClient.New(HttpClient.java:308)
at sun.net.www.http.HttpClient.New(HttpClient.java:326)
at
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1167)
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1103)
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:997)
at
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:931)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1511)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439)
at
de.flapdoodle.embed.process.store.Downloader.download(Downloader.java:76)
at
de.flapdoodle.embed.process.store.ArtifactStore.checkDistribution(ArtifactStore.java:66)
at
de.flapdoodle.embed.process.store.CachingArtifactStore.checkDistribution(CachingArtifactStore.java:56)
at de.flapdoodle.embed.process.runtime.Starter.prepare(Starter.java:52)
at
com.deere.fieldstreams.jobstreams.tilerender.session.SessionWatchSpec.init(SessionWatchSpec.scala:78)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:438)
at
org.scalatest.tools.Framework$ScalaTestTask.execute(Framework.scala:619)
at sbt.ForkMain$Run$2.call(ForkMain.java:294)
at sbt.ForkMain$Run$2.call(ForkMain.java:284)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
[error] Uncaught exception when running
com.deere.fieldstreams.jobstreams.tilerender.session.SessionWatchSpec:
de.flapdoodle.embed.process.exceptions.DistributionException:
java.net.ConnectException: Connection refused
sbt.ForkMain$ForkError: java.net.ConnectException: Connection refused
at de.flapdoodle.embed.process.runtime.Starter.prepare(Starter.java:65)
at
com.deere.fieldstreams.jobstreams.tilerender.session.SessionWatchSpec.init(SessionWatchSpec.scala:78)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:438)
at
org.scalatest.tools.Framework$ScalaTestTask.execute(Framework.scala:619)
at sbt.ForkMain$Run$2.call(ForkMain.java:294)
at sbt.ForkMain$Run$2.call(ForkMain.java:284)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
Re: Auto-generating a complex view setup
You can use the Job DSL Plugin to generate jobs and views very easily. Highly recommended method of creating jobs and/or views required for dynamic projects. The View DSL reference is here: https://github.com/jenkinsci/job-dsl-plugin/wiki/View-Reference If the views you'd like to create are not supported directly you can still do what you need using 'configure' blocks. - David On Tuesday, November 25, 2014 11:50:42 PM UTC+2, Rob Mandeville wrote: I have a matrix of n projects building on m branches, and I am putting together pipelines for each one. That is, there are a set of jobs of the form “regression tests for branch FOO of project BAR”. I have a JSON file showing the list of branches, projects, and their configurations. With that, I’ve developed an intricate system to regenerate all the jobs with no problem. Now, I just need to generate several dozen views. The hierarchy which I have been building by hand is: · (Nested View) Branch Builds o (Monitor View) All Builds for Branch FOO o (Monitor View) All Regression Tests for Branch FOO o (Nested View) Regression Pipelines for Branch FOO § (Build Pipeline View) Regression Pipeline for Branch FOO Project BAR § (Build Pipeline View) Regression Pipeline for Branch FOO Project QUX § … o (Build Pipeline View) Builds for Branch FOO Project BAR o (Build Pipeline View) Builds for Branch FOO Project QUX o … This is no longer scalable, and I’m wearing out my mouse button. I have been trying to use the Job DSL Plugin to handle this, to no avail. It has no support for monitor views, and when I try to nest nested views inside each other, the views all end up at the top level, making the tab bar ridiculously long. Is there a plugin I can use, a technique you know of, or even a way to insert views via XML without rebooting the Jenkins server? Thanks in advance, --Rob -- This e-mail and the information, including any attachments it contains, are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/48404a8e-8ecd-4e26-95b3-032732413cde%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jobs show as Pending
I've also seen this problem, I mentioned it here: https://groups.google.com/d/topic/jenkinsci-users/eetAVwKTJNU/discussion I'm also seeing a perhaps related problem where jobs with a periodic trigger are not being triggered after a while. I've opened a bug about it: https://issues.jenkins-ci.org/browse/JENKINS-25704 - David On Monday, November 17, 2014 7:56:27 PM UTC+2, Steve Gallagher wrote: Jenkins jobs show as Pending even though nothing is in front of it. But the Status page shows it counting down the minutes to zero. But when it gets to 0:00, nothing happens. On the dashboard, progress bar looks incomplete even though countdown = 0. Estimated remaining time shows N/A. This is a new glitch since we upgraded out Gerrit to 2.9. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Cloud slaves not being started by Jenkins
I'm seeing this problem as well. At some point Jenkins stops creating docker slaves. The queue shows all nodes of label 'docker' are offline, and the appropriate docker slave is not initialized. Restarting Jenkins fixes the problem for a while. Docker plugin 0.8, Jenkins 1.585. We've seen this problem in other recent versions of both the docker plugin and Jenkins. This might not be strictly Docker plugin related; we've seem some cases where builds are not being launched, (they are left at pending) though the resources are available. The logs don't show any activity by the docker plugin while the docker node is pending. Can anyone suggest additional things to check to narrow the problem down? Thanks, David On Wednesday, October 15, 2014 2:28:50 PM UTC+3, James Nord wrote: we found the latest jenkins and docker plugin work better together. Older versions would not always fire up a slave when they where supposed to - or fired up the wrong slave type! if you can upgrade to the next soon to be stable LTS and give it a go you may find it works better. On Tuesday, 14 October 2014 21:48:15 UTC+1, Richard Bywater wrote: How long have you waited for it to start a new node? I've found it can take quite a while (minutes) which apparently is caused by https://issues.jenkins-ci.org/browse/JENKINS-24752. Not sure if thats the case in your instance though. If you have a label which only contains docker providers does it work? Richard. On Wed, Oct 15, 2014 at 1:10 AM, Daniel Laird daniel@googlemail.com wrote: All, I am using the docker-plugin and provisioning containers as I require them. I am using the latest LTS Jenkins release. I have some non cloud based slaves with a label of ubuntu_12.04 and I also use this label for the docker containers. If I take all the non-cloud slaves offline (which is my goal). Then Jenkins fails to launch a slave on the cloud. I get lots of debug suggesting that there is a need for a slave: Current time: Oct 14, 2014 1:07:52 PM BST. Next execution (DIFF) in 24,780 seconds which is Oct 14, 2014 8:00:52 PM BST Oct 14, 2014 1:07:55 PM FINE hudson.slaves.NodeProvisioner Excess workload 1.0 detected. (planned capacity=0.0,Qlen=0.3694,idle=0.00,total=0m,=0.5) Oct 14, 2014 1:08:05 PM FINE hudson.slaves.NodeProvisioner Excess workload 1.0 detected. (planned capacity=0.0,Qlen=0.4326,idle=0.00,total=0m,=0.5) Oct 14, 2014 1:08:15 PM FINE hudson.slaves.NodeProvisioner Excess workload 1.0 detected. (planned capacity=0.0,Qlen=0.489,idle=0.00,total=0m,=0.5) Oct 14, 2014 1:08:25 PM FINE hudson.slaves.NodeProvisioner Excess workload 1.0 detected. (planned capacity=0.0,Qlen=0.5404,idle=0.00,total=0m,=0.5) Oct 14, 2014 1:08:35 PM FINE hudson.slaves.NodeProvisioner Excess workload 1.0 detected. (planned capacity=0.0,Qlen=0.5863,idle=0.00,total=0m,=0.5) I have enabled the following debug: com.nirima hudson.plugins hudson.slaves And I am getting no more useful debug. What do I have to do to get a Slave created? Is it a problem with the algorithm or the plugin? Hope you can help Dan -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Builds stuck at pending
Hi, I'm seeing a problem where from time to time some builds are being queued but not getting launched - despite the fact that slaves are available for the job. I'm running with Jenkins 1.585, though I've seen the problem with recent other versions (e.g. 1.582) from the last 2 months or so. I believe this is a bug and not a configuration error as jobs are usually launched correctly, and restarting Jenkins causes the previously triggered job to be launched. Can anyone suggest logging I might enable to get a better idea as to where the problem is? Have others encountered this problem as well? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Manual trigger failing in build pipeline with No upstream trigger found for this project
I've created a pipeline using the Build Pipeline plugin connecting 5 jobs like this: poll -- build-A -- deploy -- build-B -- deploy -- build-C -- deploy The poll job has a Build other projects (manual step) post-build action with build-A, build-B, build-C as the downstream project names. Looking at the build-X jobs, each show the poll job as upstream job. The pipeline view itself shows the above connections between the 5 jobs. After the poll job has run, I try to manually trigger the different build-X jobs. Only build-C is actually triggered; build-A and build-B are not triggered, with the following logged: Jul 22, 2014 5:57:06 PM SEVERE au.com.centrumsystems.hudson.plugin.buildpipeline.BuildPipelineView triggerBuild No upstream trigger found for this projectbuild-A Has anyone encountered this problem? Does anyone have something like this working? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Manual trigger failing in build pipeline with No upstream trigger found for this project
The solution: make sure there are only commas separating the projects to build specified in the post-build action. This pull request should fix the problem: https://github.com/jenkinsci/build-pipeline-plugin/pull/47 - David On Tuesday, July 22, 2014 6:30:35 PM UTC+3, David Resnick wrote: I've created a pipeline using the Build Pipeline plugin connecting 5 jobs like this: poll -- build-A -- deploy -- build-B -- deploy -- build-C -- deploy The poll job has a Build other projects (manual step) post-build action with build-A, build-B, build-C as the downstream project names. Looking at the build-X jobs, each show the poll job as upstream job. The pipeline view itself shows the above connections between the 5 jobs. After the poll job has run, I try to manually trigger the different build-X jobs. Only build-C is actually triggered; build-A and build-B are not triggered, with the following logged: Jul 22, 2014 5:57:06 PM SEVERE au.com.centrumsystems.hudson.plugin.buildpipeline.BuildPipelineView triggerBuild No upstream trigger found for this projectbuild-A Has anyone encountered this problem? Does anyone have something like this working? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Jenkins-Reviewbot failing with Perforce
I'm trying to use the Jenkins-Reviewbot plugin with Perforce as the SCM. While I managed to get a trivial patch (with a single added line to a file) to work, more complex patches fail. Has anyone managed to get the plugin working with Perforce? The problem apparently has to do with the patch format as returned by reviewboard (1.7.6 in my case). The patch has the file names as Perforce paths, i.e. prefixed with //depot/project/branch. The workaround specified in JENKINS-20396 should be enough to get this working, but for now I'm stuck. The patches fail with messages such as Caused by: java.lang.IndexOutOfBoundsException: Index: 12, Size: 12 at java.util.ArrayList.rangeCheck(ArrayList.java:604) at java.util.ArrayList.get(ArrayList.java:382) at com.cloudbees.diff.ContextualPatch.applyHunk(ContextualPatch.java:260) at com.cloudbees.diff.ContextualPatch.findHunkIndex(ContextualPatch.java:234) at com.cloudbees.diff.ContextualPatch.applyHunk(ContextualPatch.java:227) at com.cloudbees.diff.ContextualPatch.applyPatch(ContextualPatch.java:155) at com.cloudbees.diff.ContextualPatch.patch(ContextualPatch.java:108) at org.jenkinsci.plugins.jenkinsreviewbot.ReviewboardParameterValue$ApplyTask.invoke(ReviewboardParameterValue.java:225) and Caused by: com.cloudbees.diff.PatchException: Cannot apply hunk @@ 71 at com.cloudbees.diff.ContextualPatch.applyHunk(ContextualPatch.java:228) at com.cloudbees.diff.ContextualPatch.applyPatch(ContextualPatch.java:155) at com.cloudbees.diff.ContextualPatch.patch(ContextualPatch.java:108) at org.jenkinsci.plugins.jenkinsreviewbot.ReviewboardParameterValue$ApplyTask.invoke(ReviewboardParameterValue.java:225) - David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Job to show status of job on other master
I have a Jenkins instance (instance A) where I'd like to show the status of jobs running on a different Jenkins instance (instance B). I'd rather not make any change to instance A -- does anyone have a simple method for implementing this? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Problems adding jobs using Radiator View plugin
Thanks to a patch sent in from kazesberger, this should be fixed in 1.18. Uncheck Recurse in subfolders in the view. - David On Tuesday, January 14, 2014 11:12:27 PM UTC+2, MoBarger wrote: Good to know. Thank you! On Tue, Jan 14, 2014 at 2:56 PM, David Resnick abun...@gmail.comjavascript: wrote: I'm sorry to say that the problem is in Jenkins core, version 1.532.1. The bug is JENKINS-20415. This is fixed in the next (unreleased) LTS version 1.532.2. I added a compatibility section to the wiki describing this problem as well. - David On Tuesday, January 14, 2014 12:58:09 PM UTC+2, MoBarger wrote: Running Jenkins under Centos 6 x64 Oracle jvm 1.6 Jenkins 1.5.32.1 When I try to add a job to a view, it does not get saved. Throws this error: Jan 14, 2014 5:46:46 AM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.contains(job) in /jenkins/view/Feedback/configure. Reason: java.lang.ClassCastException: hudson.maven.MavenModule cannot be cast to hudson.model.TopLevelItem java.lang.ClassCastException: hudson.maven.MavenModule cannot be cast to hudson.model.TopLevelItem I see this has been reported before but I do not see a resolution. At this point all I want to do is remove the view entirely but because it does not render fully, I have no access to the lefthand navigation with the delete view link. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Problems adding jobs using Radiator View plugin
I'm sorry to say that the problem is in Jenkins core, version 1.532.1. The bug is JENKINS-20415. This is fixed in the next (unreleased) LTS version 1.532.2. I added a compatibility section to the wiki describing this problem as well. - David On Tuesday, January 14, 2014 12:58:09 PM UTC+2, MoBarger wrote: Running Jenkins under Centos 6 x64 Oracle jvm 1.6 Jenkins 1.5.32.1 When I try to add a job to a view, it does not get saved. Throws this error: Jan 14, 2014 5:46:46 AM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.contains(job) in /jenkins/view/Feedback/configure. Reason: java.lang.ClassCastException: hudson.maven.MavenModule cannot be cast to hudson.model.TopLevelItem java.lang.ClassCastException: hudson.maven.MavenModule cannot be cast to hudson.model.TopLevelItem I see this has been reported before but I do not see a resolution. At this point all I want to do is remove the view entirely but because it does not render fully, I have no access to the lefthand navigation with the delete view link. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: radaitor plugins and jenkins 1.539
Hi Luis, I hope to check why radiatorview is not working with Jenkins 1.539 in the next few days. - David On Thursday, November 21, 2013 4:32:17 PM UTC+2, Luis Lopez wrote: hello people! i installed jenkins 1.539 and my radiator view don't save the jobs selected. I need show the jobs state in a display to my team project. The walldisplay consumes many resources on the machine where it is showing the status of jobs. Is there another way to show the status of jobs? i need your help soon -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Using CLI with AD plugin
I would really appreciate it if someone could take a look at the bug I opened (JENKINS-20064 https://issues.jenkins-ci.org/browse/JENKINS-20064). The issue is present when trying to use remote access API using API token for authentication. There too, Jenkins attempts to retrieve the user from AD and fails with this error: javax.naming.NamingException: [LDAP: error code 1 - : LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece]; remaining name 'DC=mycompany,DC=com' Is this a bug or a known limitation? Can anyone explain to me how it is possible to remotely trigger a Jenkins job as an AD user? Thanks, David On Wednesday, October 16, 2013 9:12:13 AM UTC+3, David Resnick wrote: I've opened a bug for this problem. https://issues.jenkins-ci.org/browse/JENKINS-20064 - David On Monday, October 14, 2013 9:03:10 AM UTC+3, David Resnick wrote: I'm trying to use the Jenkins CLI for a server that is set up with AD as the access control security realm. Logged in users can perform any action. The Jenkins server is 1.534 on Ubuntu with Active Directory plugin 1.33, configured with just the domain (no bind DN or password). I've provisioned an SSH public key for my user. When I attempt to run CLI against Jenkins it fails with this Exception in thread main java.io.EOFException at java.io.DataInputStream.readBoolean(DataInputStream.java:244) at hudson.cli.Connection.readBoolean(Connection.java:95) at hudson.cli.CLI.authenticate(CLI.java:644) at hudson.cli.CLI._main(CLI.java:474) at hudson.cli.CLI.main(CLI.java:384) and the below is logged on the server. This is similar to JENKINS-12619 though in my case the behavior is consistent and always fails. Does anyone have this working? It an admin domain user/password required in this case? Is there any sort of workaround, such as defining a local user in Jenkins which could be used when accessing via CLI? Thanks, David Oct 13, 2013 12:23:35 PM WARNING hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider retrieveUser Failed to retrieve user information for username javax.naming.NamingException: [LDAP: error code 1 - : LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece]; remaining name 'DC=mycompany,DC=com' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3072) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2978) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2785) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1839) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1762) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1779) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:412) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:394) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376) at hudson.plugins.active_directory.LDAPSearchBuilder.search(LDAPSearchBuilder.java:52) at hudson.plugins.active_directory.LDAPSearchBuilder.searchOne(LDAPSearchBuilder.java:42) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:263) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:193) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:137) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:30) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:584) at hudson.model.User.impersonate(User.java:255) at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44) at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109) Oct 13, 2013 12:23:35 PM WARNING hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider retrieveUser Credential exception tying to authenticate against mycompany.com domain org.acegisecurity.BadCredentialsException: Failed to retrieve user information for username; nested exception is javax.naming.NamingException: [LDAP: error code 1 - : LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece]; remaining name 'DC=mycompany,DC=com
Using CLI with AD plugin
I'm trying to use the Jenkins CLI for a server that is set up with AD as the access control security realm. Logged in users can perform any action. The Jenkins server is 1.534 on Ubuntu with Active Directory plugin 1.33, configured with just the domain (no bind DN or password). I've provisioned an SSH public key for my user. When I attempt to run CLI against Jenkins it fails with this Exception in thread main java.io.EOFException at java.io.DataInputStream.readBoolean(DataInputStream.java:244) at hudson.cli.Connection.readBoolean(Connection.java:95) at hudson.cli.CLI.authenticate(CLI.java:644) at hudson.cli.CLI._main(CLI.java:474) at hudson.cli.CLI.main(CLI.java:384) and the below is logged on the server. This is similar to JENKINS-12619 though in my case the behavior is consistent and always fails. Does anyone have this working? It an admin domain user/password required in this case? Is there any sort of workaround, such as defining a local user in Jenkins which could be used when accessing via CLI? Thanks, David Oct 13, 2013 12:23:35 PM WARNING hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider retrieveUser Failed to retrieve user information for username javax.naming.NamingException: [LDAP: error code 1 - : LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece]; remaining name 'DC=mycompany,DC=com' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3072) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2978) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2785) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1839) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1762) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1779) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:412) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:394) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376) at hudson.plugins.active_directory.LDAPSearchBuilder.search(LDAPSearchBuilder.java:52) at hudson.plugins.active_directory.LDAPSearchBuilder.searchOne(LDAPSearchBuilder.java:42) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:263) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:193) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:137) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:30) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:584) at hudson.model.User.impersonate(User.java:255) at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44) at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109) Oct 13, 2013 12:23:35 PM WARNING hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider retrieveUser Credential exception tying to authenticate against mycompany.com domain org.acegisecurity.BadCredentialsException: Failed to retrieve user information for username; nested exception is javax.naming.NamingException: [LDAP: error code 1 - : LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece]; remaining name 'DC=mycompany,DC=com' at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:309) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:193) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:137) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:30) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:584) at hudson.model.User.impersonate(User.java:255) at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44) at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109) Caused by: javax.naming.NamingException: [LDAP: error code 1 - : LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection.,
Re: Tweaking 'committers' list for email-ext
Thanks a lot for your answer. I found your previously posted solution to this here: https://groups.google.com/d/msg/jenkinsci-users/2NfS9IEw52o/QPC6E88gWTcJ - David On Saturday, September 14, 2013 1:07:36 AM UTC+3, slide wrote: You could always send it along as parameters. You could use a groovy template and look back through the job causes and grab the committers at each level (I've posted on how to do this on the mailing list before). I'm sure there are other ways you can do it two, but those are the ones that pop into my head right now. On Fri, Sep 13, 2013 at 1:21 PM, David Resnick abun...@gmail.comjavascript: wrote: I have a chain of 3 jobs, A-B-C. Job A is triggered by SCM polling and job C uses the email-ext plugin to send emails to committers. My problem is that job B checks out some build script related code from a separate SCM, overridding the committers from job A. I don't mind having the job B committers (there usually aren't any) getting emails for failed job C builds, but I do need to have job A committers getting emails too. How can I set this up? What approach could I use to have the job A committers/culprits added to the recipients of emails sent by job C? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Website: http://earl-of-code.com -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Tweaking 'committers' list for email-ext
I have a chain of 3 jobs, A-B-C. Job A is triggered by SCM polling and job C uses the email-ext plugin to send emails to committers. My problem is that job B checks out some build script related code from a separate SCM, overridding the committers from job A. I don't mind having the job B committers (there usually aren't any) getting emails for failed job C builds, but I do need to have job A committers getting emails too. How can I set this up? What approach could I use to have the job A committers/culprits added to the recipients of emails sent by job C? Thanks, David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Email culprits not working in email-ext 2.33?
As a sanity check I've created a test job triggered by SCM that always fails. The email-ext configuration has a failure trigger that is set to send emails to culprits (the trigger was added directly to job config.xml due to JENKINS-19585). When I commit to SCM the job is triggered, but there is no email sent. The debug console output has this: Checking for pre-build Executing pre-build step Checking if email needs to be generated No emails were triggered. [workspace] $ cmd /c call C:\Users\dresnick\AppData\Local\Temp\hudson8412388181330090933.bat C:\Users\dresnick\.jenkins\jobs\email-test\workspaceexit 1 Build step 'Execute Windows batch command' marked build as failure Checking for post-build Performing post-build step Checking if email needs to be generated Email was triggered for: Failure Sending email for trigger: Failure NOT overriding default server settings, using Mailer to create session messageContentType = text/plain; charset=UTF-8 Successfully created MimeMessage An attempt to send an e-mail to empty list of recipients, ignored. Some error occured trying to send the email...check the Jenkins log Finished: FAILURE The job is configured like the below. Am I missing something here, or should I open a bug for this? hudson.plugins.emailext.ExtendedEmailPublisher plugin=email-ext@2.33 recipientList$DEFAULT_RECIPIENTS/recipientList configuredTriggers hudson.plugins.emailext.plugins.trigger.FailureTrigger email recipientList/recipientList subject$PROJECT_DEFAULT_SUBJECT/subject body$PROJECT_DEFAULT_CONTENT/body sendToDevelopersfalse/sendToDevelopers sendToRequesterfalse/sendToRequester sendToCulpritstrue/sendToCulprits sendToRecipientListfalse/sendToRecipientList attachmentsPattern/attachmentsPattern attachBuildLogfalse/attachBuildLog compressBuildLogfalse/compressBuildLog replyTo$PROJECT_DEFAULT_REPLYTO/replyTo contentTypeproject/contentType /email /hudson.plugins.emailext.plugins.trigger.FailureTrigger /configuredTriggers contentTypedefault/contentType defaultSubject$DEFAULT_SUBJECT/defaultSubject defaultContent$DEFAULT_CONTENT/defaultContent attachmentsPattern/attachmentsPattern presendScript$DEFAULT_PRESEND_SCRIPT/presendScript attachBuildLogfalse/attachBuildLog compressBuildLogfalse/compressBuildLog replyTo$DEFAULT_REPLYTO/replyTo saveOutputfalse/saveOutput /hudson.plugins.emailext.ExtendedEmailPublisher - David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Unable to edit job configuration
That was it -- thanks very much for pointing it out!
- David
On Tuesday, August 27, 2013 9:23:21 AM UTC+3, Geoff Cummings wrote:
Sounds like https://issues.jenkins-ci.org/browse/JENKINS-19248
Geoff
On 27 Aug 2013, at 07:12, David Resnick abun...@gmail.com javascript:
wrote:
In Chrome:
try{for(var lastpass_iter=0; lastpass_iter document.forms.length;
lastpass_iter++){ var lastpass_f = document.forms[lastpass_iter];
if(typeof(lastpass_f.lpsubmitorig2)==undefined){ lastpass_f.lpsubmitorig2
= lastpass_f.submit; lastpass_f.submit = function(){ var form=this; var
customEvent = document.createEvent(Event);
customEvent.initEvent(lpCustomEvent, true, true); var d =
document.getElementById(hiddenlpsubmitdiv); for(var i = 0; i
document.forms.length; i++){ if(document.forms[i]==form){ d.innerText=i; }
} d.dispatchEvent(customEvent); form.lpsubmitorig2(); } } }}catch(e){}
*Uncaught SyntaxError: Unexpected token ILLEGAL*
In Firefox:
[09:02:12.496] SyntaxError: invalid regular expression flag V @
http://jenkins:8080/static/0cbe8931/scripts/hudson-behavior.js:416
Not sure if either are relevant.
- David
On Mon, Aug 26, 2013 at 11:20 PM, oliver gondža ogo...@gmail.comjavascript:
wrote:
Hi, Can you check the javascript console for errors on that page?
--
oliver
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-use...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Unable to edit job configuration
In Chrome:
try{for(var lastpass_iter=0; lastpass_iter document.forms.length;
lastpass_iter++){ var lastpass_f = document.forms[lastpass_iter];
if(typeof(lastpass_f.lpsubmitorig2)==undefined){ lastpass_f.lpsubmitorig2
= lastpass_f.submit; lastpass_f.submit = function(){ var form=this; var
customEvent = document.createEvent(Event);
customEvent.initEvent(lpCustomEvent, true, true); var d =
document.getElementById(hiddenlpsubmitdiv); for(var i = 0; i
document.forms.length; i++){ if(document.forms[i]==form){ d.innerText=i; }
} d.dispatchEvent(customEvent); form.lpsubmitorig2(); } } }}catch(e){}
*Uncaught SyntaxError: Unexpected token ILLEGAL*
In Firefox:
[09:02:12.496] SyntaxError: invalid regular expression flag V @
http://jenkins:8080/static/0cbe8931/scripts/hudson-behavior.js:416
Not sure if either are relevant.
- David
On Mon, Aug 26, 2013 at 11:20 PM, oliver gondža ogon...@gmail.com wrote:
Hi, Can you check the javascript console for errors on that page?
--
oliver
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Unable to edit job configuration
Since upgrading to Jenkins 1.528 (and a slew of other plugins -- see below) job configuration pages fail to complete to load. The LOADING overlay remains, though the page otherwise seems to complete loading. Attempts to push the apply and save buttons do not complete successfully. There are no errors reported on the configuration page itself, and no errors are logged to jenkins.log. Has anyone else lately encountered such problems? Beyond rolling back individual plugins, any ideas on how I can figure out where the problem lies here? The following plugins were updated to the latest versions (after not updating for the past couple of weeks: analysis-collector analysis-core buildtriggerbadge checkstyle cobertura credentials dry email-ext external-monitor-job findbugs git-client jenkinswalldisplay maven-plugin parameterized-trigger patch-parameter pmd remote-terminal-access robot ssh-credentials ssh-slaves tasks timestamper translation warnings - David -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
email-ext tokens for Build Failure Analyzer
Great plugin! It's a huge time saver to have Jenkins figure out what went wrong with a build rather than having to view the log and figure it out for myself. Right now I'd say that the biggest improvements that could be made to the plugin involve making its results more prominent. It would be great if there was a failure reason email-ext token I could add to failure emails Jenkins sends out. I've seen that some plugins produce tokens for use by other plugins, apparently with the help of the Token Macro Plugin (e.g. https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins#StaticCodeAnalysisPlug-ins-tokens ). Also, the identified problems that appear in a build summary page is last on the page, seemingly following everything else. As far as I'm concerned, because of its importance it should be the very first item on the summary page. The lightbulb is a great way of seeing what happened with various builds without further clicking. Depending on how long descriptions are, it might be good to include additional information in the lightbulb tooltip such as the description or category. In any case, thanks for a very helpful plugin. - David
Re: email-ext tokens for Build Failure Analyzer
Right, but the Build Failure Analyzer plugin needs to create a token with its output first, doesn't it? - David On Thursday, January 3, 2013 3:26:43 PM UTC+2, slide wrote: You can use Token Macro tokens in email-ext content templates. On Thu, Jan 3, 2013 at 6:24 AM, David Resnick abun...@gmail.comjavascript: wrote: Great plugin! It's a huge time saver to have Jenkins figure out what went wrong with a build rather than having to view the log and figure it out for myself. Right now I'd say that the biggest improvements that could be made to the plugin involve making its results more prominent. It would be great if there was a failure reason email-ext token I could add to failure emails Jenkins sends out. I've seen that some plugins produce tokens for use by other plugins, apparently with the help of the Token Macro Plugin (e.g. https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins#StaticCodeAnalysisPlug-ins-tokens). Also, the identified problems that appear in a build summary page is last on the page, seemingly following everything else. As far as I'm concerned, because of its importance it should be the very first item on the summary page. The lightbulb is a great way of seeing what happened with various builds without further clicking. Depending on how long descriptions are, it might be good to include additional information in the lightbulb tooltip such as the description or category. In any case, thanks for a very helpful plugin. - David -- Website: http://earl-of-code.com
Re: email-ext tokens for Build Failure Analyzer
Indeed it is! I hope to have time to get to this at some point. - David On Thursday, January 3, 2013 3:37:42 PM UTC+2, slide wrote: Yes, it does. You could fork the plugin, add the changes in and create a pull request. Community Driven Development at its finest. On Thu, Jan 3, 2013 at 6:35 AM, David Resnick abun...@gmail.comjavascript: wrote: Right, but the Build Failure Analyzer plugin needs to create a token with its output first, doesn't it? - David On Thursday, January 3, 2013 3:26:43 PM UTC+2, slide wrote: You can use Token Macro tokens in email-ext content templates. On Thu, Jan 3, 2013 at 6:24 AM, David Resnick abun...@gmail.com wrote: Great plugin! It's a huge time saver to have Jenkins figure out what went wrong with a build rather than having to view the log and figure it out for myself. Right now I'd say that the biggest improvements that could be made to the plugin involve making its results more prominent. It would be great if there was a failure reason email-ext token I could add to failure emails Jenkins sends out. I've seen that some plugins produce tokens for use by other plugins, apparently with the help of the Token Macro Plugin (e.g. https://wiki.jenkins-ci.org/** display/JENKINS/Static+Code+**Analysis+Plug-ins#** StaticCodeAnalysisPlug-ins-**tokenshttps://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins#StaticCodeAnalysisPlug-ins-tokens). Also, the identified problems that appear in a build summary page is last on the page, seemingly following everything else. As far as I'm concerned, because of its importance it should be the very first item on the summary page. The lightbulb is a great way of seeing what happened with various builds without further clicking. Depending on how long descriptions are, it might be good to include additional information in the lightbulb tooltip such as the description or category. In any case, thanks for a very helpful plugin. - David -- Website: http://earl-of-code.**com http://earl-of-code.com -- Website: http://earl-of-code.com
Double slave for job
This is my use case: I have tests that require a collection of machines to run. There are different types of machine collections, with 1 or more instances of each type. Each collection can be used by only one driving set of tests at a time. The tests themselves do not run in the collection of machines; they can all run via ssh on the same host (or different ones, it makes no difference to me). Once the tests are finished I would like to publish reports that they generate. So the tests could run on a regular Jenkins ssh slave with a bunch of executors. But at the same time I would like to define each collection of machines as a slave, giving each collection type a different label so that test jobs would queue and wait for the appropriate type. Essentially, each machine collection slave is just a set of key value pairs (of credentials and other bits of info) to pass to the dumb ssh slave and used as test parameters, telling the tests where to run. I was wondering if there are plugins that allow a) defining a slave as a set of key value pairs and b) defining a requirement for a job to have exclusive access to 2 types of slaves before it will run on one of them. I can't recall seeing any additional types of slaves apart from the dumb one or VMs controlled by the vSphere Cloud Plugin. Are there any more? One solution I thought of is to define an ssh slave for each machine collection (they could all be on the same host), each with 1 executor and 2 labels: one generic (i.e. perf) and the other specific (i.e. perf1). Then there would be one Slave Setup Pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Slave+Setup+Pluginconfiguration per slave, each with a label matching the specific slave labels (i.e. perf1) that would copy a properties file to the root of the slave directory tree. One open question I have is where the Slave Setup Plugin copies files to; if it is to an absolute path then I wouldn't be able to reuse the same host for a number of slaves. Any thoughts or suggestions on how this could be set up (or what might be missing or which plugin almost fits to set this up) would be highly appreciated! Thanks, David
Re: Double slave for job
Since posting, I've seen that the Metadata pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Metadata+pluginwould be a great way to attach the key/values to the slaves instead of the Slave Setup Plugin. I would still be happy to hear of any ideas on how I can improve this. - David On Tuesday, December 18, 2012 9:55:06 PM UTC+2, David Resnick wrote: This is my use case: I have tests that require a collection of machines to run. There are different types of machine collections, with 1 or more instances of each type. Each collection can be used by only one driving set of tests at a time. The tests themselves do not run in the collection of machines; they can all run via ssh on the same host (or different ones, it makes no difference to me). Once the tests are finished I would like to publish reports that they generate. So the tests could run on a regular Jenkins ssh slave with a bunch of executors. But at the same time I would like to define each collection of machines as a slave, giving each collection type a different label so that test jobs would queue and wait for the appropriate type. Essentially, each machine collection slave is just a set of key value pairs (of credentials and other bits of info) to pass to the dumb ssh slave and used as test parameters, telling the tests where to run. I was wondering if there are plugins that allow a) defining a slave as a set of key value pairs and b) defining a requirement for a job to have exclusive access to 2 types of slaves before it will run on one of them. I can't recall seeing any additional types of slaves apart from the dumb one or VMs controlled by the vSphere Cloud Plugin. Are there any more? One solution I thought of is to define an ssh slave for each machine collection (they could all be on the same host), each with 1 executor and 2 labels: one generic (i.e. perf) and the other specific (i.e. perf1). Then there would be one Slave Setup Pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Slave+Setup+Pluginconfiguration per slave, each with a label matching the specific slave labels (i.e. perf1) that would copy a properties file to the root of the slave directory tree. One open question I have is where the Slave Setup Plugin copies files to; if it is to an absolute path then I wouldn't be able to reuse the same host for a number of slaves. Any thoughts or suggestions on how this could be set up (or what might be missing or which plugin almost fits to set this up) would be highly appreciated! Thanks, David
Re: NullPointerException while trying to save job configuration
Yes, I do have the Build Failure Analyzer plugin installed. Thanks for pointing out the comment in the plugin wiki. I've opened JENKINS-15986https://issues.jenkins-ci.org/browse/JENKINS-15986for this problem. - David On Wednesday, November 28, 2012 11:47:28 PM UTC+2, Larry Shatzer, Jr. wrote: Someone asked a question on the wiki page for the plugin: https://wiki.jenkins-ci.org/display/JENKINS/Build+Failure+Analyzer?focusedCommentId=65668033#comment-65668033 I also ran into the same issue, and had to disable this plugin. I just have not had time to dig into the plugin to find out what is broken with newer versions. On Wed, Nov 28, 2012 at 2:20 PM, Christopher Orr ch...@orr.me.ukjavascript: wrote: Did you install the Build Failure Analyzer plugin? I started having the exact same problems -- as mentioned in the Known Issues for that plugin -- after I installed it. Disabling the plugin fixed things again. On 26/11/2012 07:01, David Resnick wrote: Pushing Apply brings up an empty error window; pushing Save brings the below error 500 stack trace. I'm running Jenkins 1.491 with countless plugins. Any suggestions? Thanks, David Status Code: 500 Exception: java.lang.NullPointerException Stacktrace: javax.servlet.**ServletException: java.lang.NullPointerException at org.kohsuke.stapler.Stapler.**tryInvoke(Stapler.java:615) at org.kohsuke.stapler.Stapler.**invoke(Stapler.java:658) at org.kohsuke.stapler.MetaClass$**6.doDispatch(MetaClass.java:* *241) at org.kohsuke.stapler.**NameBasedDispatcher.dispatch(** NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.**tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.**invoke(Stapler.java:658) at org.kohsuke.stapler.Stapler.**invoke(Stapler.java:487) at org.kohsuke.stapler.Stapler.**service(Stapler.java:164) at javax.servlet.http.**HttpServlet.service(** HttpServlet.java:45) at winstone.ServletConfiguration.**execute(ServletConfiguration. **java:248) at winstone.RequestDispatcher.**forward(RequestDispatcher.** java:333) at winstone.RequestDispatcher.**doFilter(RequestDispatcher.** java:376) at hudson.util.**PluginServletFilter$1.** doFilter(PluginServletFilter.**java:95) at net.bull.javamelody.**MonitoringFilter.doFilter(** MonitoringFilter.java:206) at net.bull.javamelody.**MonitoringFilter.doFilter(** MonitoringFilter.java:179) at net.bull.javamelody.**PluginMonitoringFilter.**doFilter(** PluginMonitoringFilter.java:**86) at org.jvnet.hudson.plugins.**monitoring.** HudsonMonitoringFilter.**doFilter(**HudsonMonitoringFilter.java:**84) at hudson.util.**PluginServletFilter$1.** doFilter(PluginServletFilter.**java:98) at hudson.plugins.greenballs.**GreenBallFilter.doFilter(** GreenBallFilter.java:58) at hudson.util.**PluginServletFilter$1.** doFilter(PluginServletFilter.**java:98) at hudson.plugins.audit_trail.**AuditTrailFilter.doFilter(** AuditTrailFilter.java:66) at hudson.util.**PluginServletFilter$1.** doFilter(PluginServletFilter.**java:98) at hudson.util.**PluginServletFilter.doFilter(** PluginServletFilter.java:87) at winstone.FilterConfiguration.**execute(FilterConfiguration.** java:194) at winstone.RequestDispatcher.**doFilter(RequestDispatcher.** java:366) at hudson.security.csrf.**CrumbFilter.doFilter(** CrumbFilter.java:47) at winstone.FilterConfiguration.**execute(FilterConfiguration.** java:194) at winstone.RequestDispatcher.**doFilter(RequestDispatcher.** java:366) at hudson.security.**ChainedServletFilter$1.** doFilter(ChainedServletFilter.**java:84) at hudson.security.**UnwrapSecurityExceptionFilter.**doFilter(** UnwrapSecurityExceptionFilter.**java:51) at hudson.security.**ChainedServletFilter$1.** doFilter(ChainedServletFilter.**java:87) at org.acegisecurity.ui.**ExceptionTranslationFilter.**doFilter( **ExceptionTranslationFilter.**java:166) at hudson.security.**ChainedServletFilter$1.** doFilter(ChainedServletFilter.**java:87) at org.acegisecurity.providers.**anonymous.** AnonymousProcessingFilter.**doFilter(**AnonymousProcessingFilter.** java:125) at hudson.security.**ChainedServletFilter$1.** doFilter(ChainedServletFilter.**java:87) at org.acegisecurity.ui.**rememberme.** RememberMeProcessingFilter.**doFilter(**RememberMeProcessingFilter.** java:142) at hudson.security.**ChainedServletFilter$1.** doFilter(ChainedServletFilter.**java:87) at org.acegisecurity.ui.**AbstractProcessingFilter.**doFilter(** AbstractProcessingFilter.java:**271) at hudson.security.**ChainedServletFilter$1.** doFilter(ChainedServletFilter.**java:87) at org.acegisecurity.ui.**basicauth.**BasicProcessingFilter.** doFilter
NullPointerException while trying to save job configuration
Pushing Apply brings up an empty error window; pushing Save brings the below error 500 stack trace. I'm running Jenkins 1.491 with countless plugins. Any suggestions? Thanks, David Status Code: 500Exception: java.lang.NullPointerException Stacktrace: javax.servlet.ServletException: java.lang.NullPointerException at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:615) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487) at org.kohsuke.stapler.Stapler.service(Stapler.java:164) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at
Dependency Graph View Plugin side effects
It seems that the Dependency Graph View plugin is much more than advertised. In addition to viewing dependencies, it allows creating them. Am I the first to encounter this new, um, feature? I played around with the endpoints in the new Javascript graph view, making new connections and seeing what capabilities jsplumb gives. If I'm not mistaken, the new connections I created were translated to build triggers and duplications of existing dependencies. I think it would be best to disable these effects. In any case, a word of warning to users of this plugin: don't modify the graph! - David
Re: New release of Dependency Graph View Plugin with experimental Javascript visualisation
Hi Stefan, I upgraded to the new version that includes jsplumb. It doesn't seem to be working; the jsplumb tab shows a blank area, though the Json format link displays a json representation of my dependencies. Let me know if there is any further information you need. I'm attempting to view the diagram with Firefox 16.0.1 on Windows 7. - David On Tuesday, November 13, 2012 5:22:17 PM UTC+2, Stefan Wolf wrote: Hi together, I just released a new version of the https://wiki.jenkins-ci.org/display/JENKINS/Dependency+Graph+View+Plugin. This version includes an experimental visualisation via jsPlumb based on work by domi. Since I am pretty new to javascript it would be very helpful to get some feedback on this functionally, both from end-users and from developers. So please send your comments, feature and pull requests! Best regards, Stefan
Re: New release of Dependency Graph View Plugin with experimental Javascript visualisation
Working now. Looks very nice! - David On Wednesday, November 14, 2012 4:05:12 PM UTC+2, Stefan Wolf wrote: I just released version 0.6. Could you try this one? On Wednesday, November 14, 2012 6:33:23 AM UTC-3, David Resnick wrote: Hi Stefan, I upgraded to the new version that includes jsplumb. It doesn't seem to be working; the jsplumb tab shows a blank area, though the Json format link displays a json representation of my dependencies. Let me know if there is any further information you need. I'm attempting to view the diagram with Firefox 16.0.1 on Windows 7. - David On Tuesday, November 13, 2012 5:22:17 PM UTC+2, Stefan Wolf wrote: Hi together, I just released a new version of the https://wiki.jenkins-ci.org/display/JENKINS/Dependency+Graph+View+Plugin . This version includes an experimental visualisation via jsPlumb based on work by domi. Since I am pretty new to javascript it would be very helpful to get some feedback on this functionally, both from end-users and from developers. So please send your comments, feature and pull requests! Best regards, Stefan
Re: Very long load time for main dashboard since 1.486
) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at winstone.ClientOutputStream.write(ClientOutputStream.java:39) ... 70 more -- Jean-Christophe Sirot Le dimanche 21 octobre 2012 11:52:13 UTC+2, David Resnick a écrit : Since upgrading to 1.486 I've noticed long load times for some views on our Jenkins instance. Longest load times are for the main dashboard (which includes over 100 jobs and thousands of builds) -- I just timed 4 minutes 45 seconds for the page to load. Note that all pages do load eventually. Has anyone else encountered this regression? - David
Re: Very long load time for main dashboard since 1.486
Thanks! I was hoping for some attention by core developers to this thread, but I think you have made the next right step. - David On Tuesday, October 23, 2012 3:07:29 PM UTC+2, jcsirot wrote: Hi David, I opened a ticket in Jenkins JIRA: https://issues.jenkins-ci.org/browse/JENKINS-15601 Feel free to add details or comments to complete my short description of the issue. -- J.-C. Sirot Le mardi 23 octobre 2012 12:54:47 UTC+2, David Resnick a écrit : Hi Jean-Christophe, I can confirm that I have similar exceptions in my log too (you can find a sample at http://pastebin.com/NEXWMMa3 ). I am not able though to correlate the exceptions with the long loading times. Right now my main dashboard loads very quickly (with a Jenkins instance that has been up for over 5 days). - David On Tuesday, October 23, 2012 10:40:58 AM UTC+2, jcsirot wrote: Helle David, I'm facing the same issue too. Looking at the log I noticed this exception. I don't know if it is linked but after this exception has been printed in the log trail the dashboard loads immediately. Did someone have any unexpected exception in the log file? Oct 22, 2012 6:53:59 PM org.kohsuke.stapler.compression.CompressionFilter reportException WARNING: Untrapped servlet exception winstone.ClientSocketException: Failed to write to client at winstone.ClientOutputStream.write(ClientOutputStream.java:41) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:181) at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:219) at winstone.WinstoneOutputStream.close(WinstoneOutputStream.java:229) at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:149) at org.kohsuke.stapler.compression.FilterServletOutputStream.close(FilterServletOutputStream.java:36) at java.io.FilterOutputStream.close(FilterOutputStream.java:143) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:301) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:130) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:216) at java.io.BufferedWriter.close(BufferedWriter.java:248) at org.dom4j.io.XMLWriter.close(XMLWriter.java:286) at org.kohsuke.stapler.jelly.HTMLWriterOutput.close(HTMLWriterOutput.java:70) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:56) at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:625) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271
Warnings logged during startup since upgrade to 1.486
Since upgrading to 1.486 I have a lot of warnings like below logged when Jenkins starts up. There doesn't seem to be any impact to Jenkins operation. Is this a known issue? Should I open a bug about this? Thanks, David Oct 16, 2012 7:54:16 AM hudson.model.RunMap retrieve WARNING: could not load C:\jenkins\jobs\job-name\builds\574 hudson.util.IOException2: Invalid directory name C:\jenkins\jobs\job-name\builds\574 at hudson.model.Run.parseTimestampFromBuildDir(Run.java:332) at hudson.model.Run.init(Run.java:278) at hudson.model.AbstractBuild.init(AbstractBuild.java:182) at hudson.model.Build.init(Build.java:103) at hudson.model.FreeStyleBuild.init(FreeStyleBuild.java:41) at sun.reflect.GeneratedConstructorAccessor39.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at hudson.model.AbstractProject.loadBuild(AbstractProject.java:1061) at hudson.model.AbstractProject$1.create(AbstractProject.java:275) at hudson.model.AbstractProject$1.create(AbstractProject.java:273) at hudson.model.RunMap.retrieve(RunMap.java:220) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:613) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:576) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:338) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:210) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:303) at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:613) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:596) at jenkins.model.lazy.AbstractLazyLoadRunMap.all(AbstractLazyLoadRunMap.java:549) at jenkins.model.lazy.AbstractLazyLoadRunMap.entrySet(AbstractLazyLoadRunMap.java:234) at java.util.AbstractMap$2$1.init(Unknown Source) at java.util.AbstractMap$2.iterator(Unknown Source) at hudson.util.RunList.iterator(RunList.java:103) at org.jvnet.hudson.plugins.DownStreamProjectActionFactory.createFor(DownStreamProjectActionFactory.java:59) at hudson.model.AbstractProject.createTransientActions(AbstractProject.java:675) at hudson.model.Project.createTransientActions(Project.java:208) at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:665) at hudson.model.AbstractProject.onLoad(AbstractProject.java:299) at hudson.model.Project.onLoad(Project.java:88) at hudson.model.Items.load(Items.java:221) at jenkins.model.Jenkins$17.run(Jenkins.java:2507) 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$7.runTask(Jenkins.java:883) 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.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.text.ParseException: Unparseable date: 574 at java.text.DateFormat.parse(Unknown Source) at hudson.model.Run.parseTimestampFromBuildDir(Run.java:330) ... 43 more
Very long load time for main dashboard since 1.486
Since upgrading to 1.486 I've noticed long load times for some views on our Jenkins instance. Longest load times are for the main dashboard (which includes over 100 jobs and thousands of builds) -- I just timed 4 minutes 45 seconds for the page to load. Note that all pages do load eventually. Has anyone else encountered this regression? - David
Re: Very long load time for main dashboard since 1.486
Right, I'm also guessing that this is related to the lazy loading that was added in 1.485. Unfortunately, the long loading times are fairly consistent; the 5 minute time I mentioned was not the first time I loaded the main dashboard. In any case, while I expect lazy loading of builds to increase first time page load times I don't think that such a long load time for a page would be acceptable to any user of Jenkins. - David On Sunday, October 21, 2012 12:38:55 PM UTC+2, Richard Mortimer wrote: On 21/10/2012 10:52, David Resnick wrote: Since upgrading to 1.486 I've noticed long load times for some views on our Jenkins instance. Longest load times are for the main dashboard (which includes over 100 jobs and thousands of builds) -- I just timed 4 minutes 45 seconds for the page to load. Note that all pages do load eventually. Has anyone else encountered this regression? Not specifically but it could be due to the lazy loading of build information that was introduced in 1.485. I guess that is the flip side of having faster startup times. Does a second load of the page work quicker? That might be some useful feedback to provide to jenkin...@googlegroups.com javascript: if it is causing problems. Regards Richard - David
Re: Very long load time for main dashboard since 1.486
No, I'm not using that plugin. Thanks for pointing out a possible cause for my problems. - David On Sunday, October 21, 2012 5:45:06 PM UTC+2, Baptiste Mathus wrote: Hi, Just a small guess: are you using nested view plugin? If so, it might alternatively be related to another problem introduced recently in the nested-view plugin (see recent archives about that, thread started by mpapo). Btw, it's been fixed since we logged the issue. My 2 cents. Cheers Le 21 oct. 2012 13:27, David Resnick abun...@gmail.com javascript: a écrit : Right, I'm also guessing that this is related to the lazy loading that was added in 1.485. Unfortunately, the long loading times are fairly consistent; the 5 minute time I mentioned was not the first time I loaded the main dashboard. In any case, while I expect lazy loading of builds to increase first time page load times I don't think that such a long load time for a page would be acceptable to any user of Jenkins. - David On Sunday, October 21, 2012 12:38:55 PM UTC+2, Richard Mortimer wrote: On 21/10/2012 10:52, David Resnick wrote: Since upgrading to 1.486 I've noticed long load times for some views on our Jenkins instance. Longest load times are for the main dashboard (which includes over 100 jobs and thousands of builds) -- I just timed 4 minutes 45 seconds for the page to load. Note that all pages do load eventually. Has anyone else encountered this regression? Not specifically but it could be due to the lazy loading of build information that was introduced in 1.485. I guess that is the flip side of having faster startup times. Does a second load of the page work quicker? That might be some useful feedback to provide to jenkin...@googlegroups.com if it is causing problems. Regards Richard - David
