[JIRA] (JENKINS-46067) Pipeline task scheduled on uninitialized node
Title: Message Title Russell Gallop commented on JENKINS-46067 Re: Pipeline task scheduled on uninitialized node I don't know for sure whether it was Java Web or some other way, but definitely a permanent node. Is it possible that it happens more with automatically created agents as they are added/removed more frequently? It's not something we see frequently so we could have just been unlucky! Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-46067) Pipeline task scheduled on uninitialized node
Title: Message Title Russell Gallop commented on JENKINS-46067 Re: Pipeline task scheduled on uninitialized node We saw this but are not using Docker Slaves or AWS EC2 plugin. We are using windows machines connected via JNLP. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54513) Builds occupying executor but not running
Title: Message Title
Russell Gallop edited a comment on JENKINS-54513
Re: Builds occupying executor but not running
Just seen what seems to be this same issue again. On this occasion it was all one job running parallel on a couple of Linux machines. In this case the job was reporting:{code:java}[TASK1] Still waiting to schedule task[TASK2] Still waiting to schedule task[TASK3] Still waiting to schedule task[TASK4] Still waiting to schedule task {code}There were only 3 executors available for this and according to the Build Executor Status they have all been assigned to " » #476 (part)".In this case there were blocked threads in PrintStream.java:805 but not the ones I saw before in PrintStream.java:355 (threads on master):{code:java} Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[56:node]:Owner[//476:/ #476],cookie=null,auth=null}"Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[56:node]:Owner[//476:/ #476],cookie=null,auth=null}" Id=5916973 Group=main BLOCKED on java.io.PrintStream@208dc6f1 owned by "jenkins.util.Timer [#9]" Id=80 at java.io.PrintStream.println(PrintStream.java:805) - blocked on java.io.PrintStream@208dc6f1 at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask$PlaceholderExecutable.run(ExecutorStepExecution.java:694) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429)Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[62:node]:Owner[//476:/ #476],cookie=null,auth=null}"Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[62:node]:Owner[//476:/ #476],cookie=null,auth=null}" Id=5917131 Group=main BLOCKED on java.io.PrintStream@107ec0b6 owned by "jenkins.util.Timer [#10]" Id=81 at java.io.PrintStream.println(PrintStream.java:805) - blocked on java.io.PrintStream@107ec0b6 at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask$PlaceholderExecutable.run(ExecutorStepExecution.java:694) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429)Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[59:node]:Owner[//476:/ #476],cookie=null,auth=null}"Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[59:node]:Owner[//476:/ #476],cookie=null,auth=null}" Id=5917098 Group=main BLOCKED on java.io.PrintStream@7e577653 owned by "jenkins.util.Timer [#2]" Id=65 at java.io.PrintStream.println(PrintStream.java:805) - blocked on java.io.PrintStream@7e577653 at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask$PlaceholderExecutable.run(ExecutorStepExecution.java:694) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429){code}As before there are no processes being run by the Jenkins agent.The Timer threads look like:{code:java}jenkins.util.Timer [#10]jenkins.util.Timer [#10]"jenkins.util.Timer [#10]" Id=81 Group=main RUNNABLE (in native) at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at java.io.PrintStream.write(PrintStream.java:480) - locked java.io.PrintStream@107ec0b6 at
[JIRA] (JENKINS-54513) Builds occupying executor but not running
Title: Message Title
Russell Gallop commented on JENKINS-54513
Re: Builds occupying executor but not running
Just seen what seems to be this same issue again. On this occasion it was all one job running parallel on a couple of Linux machines. In this case the job was reporting:
[TASK1] Still waiting to schedule task
[TASK2] Still waiting to schedule task
[TASK3] Still waiting to schedule task
[TASK4] Still waiting to schedule task
There were only 3 executors available for this and according to the Build Executor Status they have all been assigned to " » #476 (part)". In this case there were blocked threads in PrintStream.java:805 but not the ones I saw before in PrintStream.java:355 (threads on master):
Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[56:node]:Owner[//476:/ #476],cookie=null,auth=null}
"Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[56:node]:Owner[//476:/ #476],cookie=null,auth=null}" Id=5916973 Group=main BLOCKED on java.io.PrintStream@208dc6f1 owned by "jenkins.util.Timer [#9]" Id=80
at java.io.PrintStream.println(PrintStream.java:805)
- blocked on java.io.PrintStream@208dc6f1
at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask$PlaceholderExecutable.run(ExecutorStepExecution.java:694)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[62:node]:Owner[//476:/ #476],cookie=null,auth=null}
"Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[62:node]:Owner[//476:/ #476],cookie=null,auth=null}" Id=5917131 Group=main BLOCKED on java.io.PrintStream@107ec0b6 owned by "jenkins.util.Timer [#10]" Id=81
at java.io.PrintStream.println(PrintStream.java:805)
- blocked on java.io.PrintStream@107ec0b6
at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask$PlaceholderExecutable.run(ExecutorStepExecution.java:694)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[59:node]:Owner[//476:/ #476],cookie=null,auth=null}
"Executor #0 for : executing PlaceholderExecutable:ExecutorStepExecution.PlaceholderTask{runId=/#476,label=,context=CpsStepContext[59:node]:Owner[//476:/ #476],cookie=null,auth=null}" Id=5917098 Group=main BLOCKED on java.io.PrintStream@7e577653 owned by "jenkins.util.Timer [#2]" Id=65
at java.io.PrintStream.println(PrintStream.java:805)
- blocked on java.io.PrintStream@7e577653
at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask$PlaceholderExecutable.run(ExecutorStepExecution.java:694)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at
[JIRA] (JENKINS-54513) Builds occupying executor but not running
Title: Message Title Russell Gallop updated an issue Jenkins / JENKINS-54513 Builds occupying executor but not running Change By: Russell Gallop Summary: Jobs Builds occupying executor but not running Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54513) Jobs occupying executor but not running
Title: Message Title
Russell Gallop created an issue
Jenkins / JENKINS-54513
Jobs occupying executor but not running
Issue Type:
Bug
Assignee:
Unassigned
Attachments:
BuildExecutors.PNG, BuildHistory.PNG, threadDump.txt
Components:
core
Created:
2018-11-07 13:08
Environment:
jenkins 2.107.3
Priority:
Major
Reporter:
Russell Gallop
We have seen a couple of jobs which appear to have got executors stuck while starting the build. For example one buildhas console output (build #428) Started by upstream project "/" build number 181 originally caused by: {{ Started by upstream project "/" build number 852}} {{ originally caused by:}} {{ Started by upstream project "/" build number 1569}} {{ originally caused by:}} {{ Started by user }} {{ Replayed #1568}} Resume disabled by user, switching to high-performance, low-durability mode. [Pipeline] node Still waiting to schedule task Aborted by Click here to forcibly terminate running steps Click here to forcibly kill entire build Hard kill! Finished: ABORTED And according the build history of that job it has been aborted. However, in the Build Executor Status an executor has been allocated and it believe that it is still running. Trying to abort from Build Executor Status doesn't do anything. This happened across 4 jobs which were run in parallel, triggered by another job and were started within 2 seconds of each other. I could not see any blocked threads on the node (and we have tried restarting the Jenkins agent service) to no avail. There are some blocked threads on the master, see threadDump.txt. It looks like this is
[JIRA] (JENKINS-45999) Provide light weight checkout functionality for perforce in pipeline jobs
Title: Message Title
Russell Gallop commented on JENKINS-45999
Re: Provide light weight checkout functionality for perforce in pipeline jobs
I'm trying to understand what this means:
The client name and client view mapping will be modified from a template name e.g. jenkins-${NODE_NAME}-${JOB_NAME} to the temporary name jenkinsTemp-UUID. Alternativly if a user as used ${P4_CLIENT} in the client mapping this will remain unchanged and will be get expanded during the job run.
I would like it to mean that if I specify my own "Workspace name" and then use "${P4_CLIENT}" in "View Mappings", then it will use my workspace name instead of jenkinsTemp-UUID. That doesn't appear to work this way. View Mapping remains unchanged but "Workspace name gets replaced. This is annoying as it is creating (and not destroying) a large number of perforce workspaces which is bogging down our p4 server. Is this supposed to allow user override of the workspace name, if so then I believe that it doesn't do that (on version 1.8.10)?
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54106) Long delay from github webhook to polling when polling threads all busy
Title: Message Title Russell Gallop commented on JENKINS-54106 Re: Long delay from github webhook to polling when polling threads all busy I have worked around this by adding a separate job which just does the polling and then triggers the Matrix+Multi-SCM job. That seems to avoid the extraneous triggering. SCM Polling threads are a resource where the user is left to find the "correct" configuration. As such it would be useful if metrics were made available for things like: How many SCM polling threads are busy How long SCM poll tasks have had to wait How long SCM polls tasks are taking That would help enormously in debugging problems such as this. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54106) Long delay from github webhook to polling when polling threads all busy
Title: Message Title Russell Gallop updated an issue Jenkins / JENKINS-54106 Long delay from github webhook to polling when polling threads all busy Change By: Russell Gallop Component/s: p4-plugin Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54106) Long delay from github webhook to polling when polling threads all busy
Title: Message Title
Russell Gallop commented on JENKINS-54106
Re: Long delay from github webhook to polling when polling threads all busy
Using "refs/heads/" and removing the path filter doesn't prevent the erroneous triggering, but it does seem to be quicker (possibly as no builds are going on). Started on Oct 17, 2018 11:34:11 AM Started by event from ? https:///github-webhook/ on Wed Oct 17 11:34:00 BST 2018 Using strategy: Default [poll] Last Built Revision: Revision acc6ad05f1a8e98bc1cebec53ffdf695fad7fca2 (origin/) {{ > git --version # timeout=30}} using GIT_SSH to set credentials {{ > git ls-remote -h # timeout=30}} Found 347 remote heads on [poll] Latest remote head revision on refs/heads/ is: acc6ad05f1a8e98bc1cebec53ffdf695fad7fca2 - already built by 186 P4: Polling on: master with: Done. Took 3.7 sec Changes found
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54106) Long delay from github webhook to polling when polling threads all busy
Title: Message Title Russell Gallop commented on JENKINS-54106 Re: Long delay from github webhook to polling when polling threads all busy A workaround is to identify the offending job by looking at the thread dump and disable that job. After that and killing the erroneously triggered builds the queue of SCM triggers gets through. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54106) Long delay from github webhook to polling when polling threads all busy
Title: Message Title
Russell Gallop commented on JENKINS-54106
Re: Long delay from github webhook to polling when polling threads all busy
I'm not sure whether it is easy to replicate but I'm seeing it again and will try to describe the set up as closely as possible. This follows a migration of a repository from Bitbucket (using git/notifyCommit) to Github (with webhook notifications). The jobs that appear to be causing the problem are older Matrix jobs which use multi-scm with git and p4-plugin. That job has triggered several times overnight despite there not being any relevant changes. A polling log from overnight on that job looks like: Started on Oct 17, 2018 8:33:15 AM Started by event from 43.148.32.90 ? https:///github-webhook/ on Wed Oct 17 03:09:33 BST 2018 Polling SCM changes on Using strategy: Default [poll] Last Built Revision: Revision acc6ad05f1a8e98bc1cebec53ffdf695fad7fca2 (origin/) {{ > git rev-parse --is-inside-work-tree # timeout=30}} Fetching changes from the remote Git repositories {{ > git config remote.origin.url # timeout=30}} Fetching upstream changes from {{ > git --version # timeout=30}} using GIT_SSH to set credentials {{ > git fetch --tags --progress g...@github.sie.sony.com:SIE-Private/cpu-toolchain-orbis.git +refs/heads/:refs/remotes/origin/ # timeout=180}} Polling for changes in {{ > git rev-parse "origin/^{commit}" # timeout=30}} {{ > git rev-parse "^{commit}" # timeout=30}} P4: Polling on: with: Done. Took 1 hr 17 min Changes found This job requires "Polling ignores commits in certain paths" so will have to use a local checkout. This is a large repository so takes a while to checkout (~15 minutes). All 10 SCM polling threads appear to be busy on this job: Waiting to acquire C:\j\w\ : GitHubPushTrigger 10. It is not surprising that this is backing up as github push notifications can happen about on average about every 20 minutes and the poll operation took 1h17. This raises the following questions:
Why is it taking so long?
Why is it triggering a job when there are no relevant changes?
We had a build of that job running from 8:29am and a new one at 9:51am so it seems like the polling job starting at 8:33am may have been waiting for the build to finish. The matrix parent and one of the configurations ran on the same agent as the polling agent. That might explain 1. So it seems to me like Jenkins takes git pushes in, allocates an SCM polling thread to poll them, which finds the best agent to poll with, which picks the last agent it polled with, which is currently busy running a build. More SCM notifications come in and repeat the pattern and things back up, all waiting for the build to finish with the agent and the git checkout that is is using. I don't know what the queueing policy is like between SCM triggers and builds but it seems like if you have triggers coming in quicker than your builds then this will back up even if there are no relevant changes. I've noticed that I'm not using the "refs/heads/" form of branch in the configuration so I'll try that to avoid 2. I also haven't removed the old repository checkouts since migrating so I'll try that as well (it is the same git data and I haven't seen this being a problem elsewhere but might be best to be sure). I might be able to remove the git path filter which might help as well (not ideal but better than all triggers being delayed by hours!). Thanks
[JIRA] (JENKINS-54106) Long delay from github webhook to polling
Title: Message Title Russell Gallop edited a comment on JENKINS-54106 Re: Long delay from github webhook to polling It looks like all 10 of the SCM polling threads were stuck processing another job. (e.g.) h2. SCMTrigger [#3]"SCMTrigger [#3]" Id=334 Group=main WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@7088b71d at sun.misc.Unsafe.park(Native Method) - waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@7088b71d at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)h2. Waiting to acquire C:\j\w\JobName : GitHubPushTrigger [#3]"Waiting to acquire C:\j\w\JobName : GitHubPushTrigger [#3]" Id=857002 Group=main WAITING on hudson.slaves.WorkspaceList@744f269b at java.lang.Object.wait(Native Method) - waiting on hudson.slaves.WorkspaceList@744f269b at java.lang.Object.wait(Object.java:502) at hudson.slaves.WorkspaceList.acquire(WorkspaceList.java:257) at hudson.slaves.WorkspaceList.acquire(WorkspaceList.java:236) at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1405) at hudson.model.AbstractProject._poll(AbstractProject.java:1382) at hudson.model.AbstractProject.poll(AbstractProject.java:1293) at jenkins.triggers.SCMTriggerItem$SCMTriggerItems$Bridge.poll(SCMTriggerItem.java:143) at com.cloudbees.jenkins.GitHubPushTrigger$1.runPolling(GitHubPushTrigger.java:109) at com.cloudbees.jenkins.GitHubPushTrigger$1.run(GitHubPushTrigger.java:135) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:119) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Number of locked synchronizers = 1 - java.util.concurrent.ThreadPoolExecutor$Worker@4045db32 Add Comment
[JIRA] (JENKINS-54106) Long delay from github webhook to polling
Title: Message Title Russell Gallop commented on JENKINS-54106 Re: Long delay from github webhook to polling It looks like all 10 of the SCM polling threads were stuck processing another job. SCMTrigger 3 "SCMTrigger 3" Id=334 Group=main WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@7088b71d at sun.misc.Unsafe.park(Native Method) - waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@7088b71d at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) Waiting to acquire C:\j\w\JobName : GitHubPushTrigger 3 "Waiting to acquire C:\j\w\JobName : GitHubPushTrigger 3" Id=857002 Group=main WAITING on hudson.slaves.WorkspaceList@744f269b at java.lang.Object.wait(Native Method) - waiting on hudson.slaves.WorkspaceList@744f269b at java.lang.Object.wait(Object.java:502) at hudson.slaves.WorkspaceList.acquire(WorkspaceList.java:257) at hudson.slaves.WorkspaceList.acquire(WorkspaceList.java:236) at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1405) at hudson.model.AbstractProject._poll(AbstractProject.java:1382) at hudson.model.AbstractProject.poll(AbstractProject.java:1293) at jenkins.triggers.SCMTriggerItem$SCMTriggerItems$Bridge.poll(SCMTriggerItem.java:143) at com.cloudbees.jenkins.GitHubPushTrigger$1.runPolling(GitHubPushTrigger.java:109) at com.cloudbees.jenkins.GitHubPushTrigger$1.run(GitHubPushTrigger.java:135) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:119) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Number of locked synchronizers = 1 - java.util.concurrent.ThreadPoolExecutor$Worker@4045db32 Add Comment
[JIRA] (JENKINS-54106) Long delay from github webhook to polling
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-54106
Long delay from github webhook to polling
Change By:
Russell Gallop
I am seeing some long delays between github webhook events and jobs polling for changes (e.g. from GitHub Hook Log). Note the almost 17 1/2 hour gap between the event being received and the polling being performed. {{Started on Oct 16, 2018 2:46:44 PM}} {{Started by event from 43.148.32.90 ? https:///github-webhook/ on Mon Oct 15 21:19:54 BST 2018}} {{[poll] Last Built Revision: Revision c7013e0bb447b77bf13e719201ce2acb44b073af (refs/remotes/origin/)}} \{{ > git --version # timeout=30}} {{using GIT_SSH to set credentials }} \{{ > git ls-remote -h # timeout=30}} {{Found 345 remote heads on }} {{[poll] Latest remote head revision on refs/heads/ is: c7013e0bb447b77bf13e719201ce2acb44b073af - already built by 34835}} {{Done. Took 3 sec}} {{No changes}} I have checked that github is sending the webhook notifications and these get a http 200 response code.The Jenkins Log reports the PushEvents are being received and that my build job is being "Poked" but polling is not being run for the job. {{Oct 16, 2018 3:29:50 PM FINEST org.jenkinsci.plugins.github.webhook.GHEventPayload$PayloadHandler parse}} \{{Payload }}{{...}} {{Oct 16, 2018 3:29:50 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber onEvent}} {{Received PushEvent for https: from ⇒ https:///github-webhook/}} {{Oct 16, 2018 3:29:51 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run}} {{Considering to poke my_build}} {{Oct 16, 2018 3:29:51 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run}} {{Poked my_build}} The agent that my_build runs on is not permanently busy.Any idea what is going on here? How can I debug this further?We have a lot of jobs (~1000) and possibly a lot (10s) of SCM polls happening. How can jobs polling SCMs but I see a log of these or examine the queue of SCM polls waiting? can't imagine this would take 17 1/2 hours...
Add Comment
[JIRA] (JENKINS-54106) Long delay from github webhook to polling
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-54106
Long delay from github webhook to polling
Change By:
Russell Gallop
I am seeing some long delays between github webhook events and jobs polling for changes (e.g. from GitHub Hook Log). Note the almost 17 1/2 hour gap between the event being received and the polling being performed. {{Started on Oct 16, 2018 2:46:44 PM}} {{Started by event from 43.148.32.90 ? https:///github-webhook/ on Mon Oct 15 21:19:54 BST 2018}} {{[poll] Last Built Revision: Revision c7013e0bb447b77bf13e719201ce2acb44b073af (refs/remotes/origin/)}} \{{ > git --version # timeout=30}} {{using GIT_SSH to set credentials }} \{{ > git ls-remote -h # timeout=30}} {{Found 345 remote heads on }} {{[poll] Latest remote head revision on refs/heads/ is: c7013e0bb447b77bf13e719201ce2acb44b073af - already built by 34835}} {{Done. Took 3 sec}} {{No changes}} I have checked that github is sending the webhook notifications and these get a http 200 response code.The Jenkins Log reports the PushEvents are being received and that my build job is being "Poked" but polling is not being run for the job. {{Oct 16, 2018 3:29:50 PM FINEST org.jenkinsci.plugins.github.webhook.GHEventPayload$PayloadHandler parse}} \{{Payload }}{{...}} {{Oct 16, 2018 3:29:50 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber onEvent}} {{Received PushEvent for https: from ⇒ https:///github-webhook/}} {{Oct 16, 2018 3:29:51 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run}} {{Considering to poke my_build}} {{Oct 16, 2018 3:29:51 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run}} {{Poked my_build}} The agent that my_build runs on is not permanently busy.Any idea what is going on here? How can I debug this further? We have a lot of jobs and possibly a lot of SCM polls happening. How can I see a log of these or examine the queue of SCM polls waiting?
Add Comment
[JIRA] (JENKINS-54106) Long delay from github webhook to polling
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-54106
Long delay from github webhook to polling
Change By:
Russell Gallop
I am seeing some long delays between github webhook events and jobs polling for changes (e.g. from GitHub Hook Log). Note the almost 17 1/2 hour gap between the event being received and the polling being performed. {{Started on Oct 16, 2018 2:46:44 PM}}{{Started by event from 43.148.32.90 ? https:///github-webhook/ on Mon Oct 15 21:19:54 BST 2018}}{{[poll] Last Built Revision: Revision c7013e0bb447b77bf13e719201ce2acb44b073af (refs/remotes/origin/)}} \ {{ > git --version # timeout=30}}{{using GIT_SSH to set credentials }} \ {{ > git ls-remote -h # timeout=30}}{{Found 345 remote heads on }}{{[poll] Latest remote head revision on refs/heads/ is: c7013e0bb447b77bf13e719201ce2acb44b073af - already built by 34835}}{{Done. Took 3 sec}}{{No changes}} I have checked that github is sending the webhook notifications and these get a http 200 response code.The Jenkins Log reports the PushEvents are being received and that my build job is being "Poked" but polling is not being run for the job . {{Oct 16, 2018 3:29:50 PM FINEST org.jenkinsci.plugins.github.webhook.GHEventPayload$PayloadHandler parse}} \ {{Payload }}{{...}}{{Oct 16, 2018 3:29:50 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber onEvent}}{{Received PushEvent for https: from ⇒ https:///github-webhook/}}{{Oct 16, 2018 3:29:51 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run}}{{Considering to poke my_build}}{{Oct 16, 2018 3:29:51 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run}}{{Poked my_build}} The agent that my_build runs on is not permanently busy.Any idea what is going on here? How can I debug this further?
Add Comment
[JIRA] (JENKINS-54106) Long delay from github webhook to polling
Title: Message Title
Russell Gallop created an issue
Jenkins / JENKINS-54106
Long delay from github webhook to polling
Issue Type:
Bug
Assignee:
Mark Waite
Components:
git-plugin, github-plugin
Created:
2018-10-16 15:15
Environment:
jenkins 2.107.3 git-plugin 3.9.0 github-plugin 1.29.0 github API 1.90
Priority:
Major
Reporter:
Russell Gallop
I am seeing some long delays between github webhook events and jobs polling for changes (e.g. from GitHub Hook Log). Note the almost 17 1/2 hour gap between the event being received and the polling being performed. Started on Oct 16, 2018 2:46:44 PM Started by event from 43.148.32.90 ? https:///github-webhook/ on Mon Oct 15 21:19:54 BST 2018 [poll] Last Built Revision: Revision c7013e0bb447b77bf13e719201ce2acb44b073af (refs/remotes/origin/) {{ > git --version # timeout=30}} using GIT_SSH to set credentials {{ > git ls-remote -h # timeout=30}} Found 345 remote heads on [poll] Latest remote head revision on refs/heads/ is: c7013e0bb447b77bf13e719201ce2acb44b073af - already built by 34835 Done. Took 3 sec No changes I have checked that github is sending the webhook notifications and these get a http 200 response code. The Jenkins Log reports the PushEvents are being received and that my build is being "Poked". Oct 16, 2018 3:29:50 PM FINEST org.jenkinsci.plugins.github.webhook.GHEventPayload$PayloadHandler parse {{Payload }} ... Oct 16, 2018 3:29:50 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber onEvent Received PushEvent for https: from ⇒ https:///github-webhook/ Oct 16, 2018 3:29:51 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run Considering to poke my_build Oct 16, 2018 3:29:51 PM INFO
[JIRA] (JENKINS-33761) Ability to disable Pipeline durability and "resume" build.
Title: Message Title
Russell Gallop commented on JENKINS-33761
Re: Ability to disable Pipeline durability and "resume" build.
Thread dump from a node this is happening on attached. Jenkins 2.107.3 Pipeline 2.5 Pipeline API 2.27 Pipeline Nodes and Processes 2.19 Pipeline Step API 2.15 JENKINS-33671_thread_dump.txt Oddly, having killed the job from "Build Executor Status" the node is freed up but the job seems to still think it is running:
[Pipeline] {
Creating placeholder flownodes because failed loading originals.
Resuming build at Thu Sep 20 11:47:46 BST 2018 after Jenkins restart
[Pipeline] End of Pipeline
Finished: FAILURE
The next thing that this would be doing would be retry { checkout git ... }
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-33761) Ability to disable Pipeline durability and "resume" build.
Title: Message Title Russell Gallop updated an issue Jenkins / JENKINS-33761 Ability to disable Pipeline durability and "resume" build. Change By: Russell Gallop Attachment: JENKINS-33671_thread_dump.txt Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-33761) Ability to disable Pipeline durability and "resume" build.
Title: Message Title Russell Gallop commented on JENKINS-33761 Re: Ability to disable Pipeline durability and "resume" build. We have seen the same thing. Resume definitely disabled and still causing hangs. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-43556) Stage View shows incorrect build result
Title: Message Title Russell Gallop commented on JENKINS-43556 Re: Stage View shows incorrect build result I've seen this again and checked the files in the file store. I can't see any problems in them. I don't think I can send them all but I have a copy stored so if there is anything useful for me to look for I can. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-43556) Stage View shows incorrect build result
Title: Message Title Russell Gallop commented on JENKINS-43556 Re: Stage View shows incorrect build result Similar to Adam, I don't think that it can be reproduced just from the pipeline DSL. I have seen this happen on one build and be okay on the ones just before and after. I have produced a small script to find instances of this problem by spotting differences between the wfapi and the main Jenkins API (attached) JENKINS-43556.py. This didn't find any more examples of the problem so it seems that it happened 3 times within about 24 hours but not since. We have since restarted Jenkins (and updated 2.73.3 -> 2.98.3) and can no longer see the problem with the previous builds in the wfapi, they have long since disappeared from the pipeline view. I had a look at the workflow files in the Jenkins filesystem for these jobs (after the restart) and can't see any problems (e.g. incorrect status) in the files there. JENKINS-43556.py Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-43556) Stage View shows incorrect build result
Title: Message Title Russell Gallop updated an issue Jenkins / JENKINS-43556 Stage View shows incorrect build result Change By: Russell Gallop Attachment: JENKINS-43556.py Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-43556) Stage View shows incorrect build result
Title: Message Title Russell Gallop edited a comment on JENKINS-43556 Re: Stage View shows incorrect build result I also see this with jenkins 2.73.3, pipeline stage view 2.9 and pipeline rest api plugin 2.9.Build history view on the left shows success, stage view shows the whole row in red with no cell highlighted in stripey red.The normal api for the build: //api/python?pretty=true says "result": "SUCCESS"The wfapi: /wfapi/ run runs shows as having "status": "FAILED" . All stages within that report "SUCCESS".The pipeline steps view shows SUCCESS for every step so it seems like a problem with the overall status from the wfapi. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-43556) Stage View shows incorrect build result
Title: Message Title Russell Gallop assigned an issue to Sam Van Oort Jenkins / JENKINS-43556 Stage View shows incorrect build result Change By: Russell Gallop Assignee: Sam Van Oort Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-43556) Stage View shows incorrect build result
Title: Message Title Russell Gallop commented on JENKINS-43556 Re: Stage View shows incorrect build result I also see this with jenkins 2.73.3, pipeline stage view 2.9 and pipeline rest api plugin 2.9. Build history view on the left shows success, stage view shows the whole row in red with no cell highlighted in stripey red. The normal api for the build: //api/python?pretty=true says "result": "SUCCESS" The wfapi: /wfapi/run shows as having "status": "FAILED" . All stages within that report "SUCCESS". The pipeline steps view shows SUCCESS for every step so it seems like a problem with the overall status from the wfapi. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42885) wfapi incorrectly reporting build job status
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-42885
wfapi incorrectly reporting build job status
Change By:
Russell Gallop
The wfapi can end up reporting an incorrect status for a child job it the original trigger jon job 's result is forced to unstable.The following test case has two jobs the trigger job and the child job. The trigger job builds the child job, waits on it and then sets its own results to UNSTABLE. The child job finishes with a success result.What I expect is to be able to look into the wfapi and see that the child job actually was a success, however it is marked as unstable.In a similar case where the trigger job result is set to FAILURE the status of the child job is SUCCESSTestcase:{noformat}Child Job:node { currentBuild.setResult("SUCCESS")}Trigger Job:stage ('run'){def parallel_infobuild job: "expected_success", propagate: falsecurrentBuild.setResult('UNSTABLE')}{noformat}
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-41482) Pipeline bat step hangs (after restart)
Title: Message Title Russell Gallop commented on JENKINS-41482 Re: Pipeline bat step hangs (after restart) In trying to create a reproducible case for this I found the "consume.exe" program from the Windows SDK, which can simulate CPU load (consume -cpu-time -time 60). With this CPU load I have seen a number of issues, including pipeline hangs on restart, pipeline job failure on restart and java.exe being orphaned by the Windows service wrapper. None of these are "reliably" reproducible so I haven't been able to report an exact case but are similar to things we have seen happen in the wild. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41482) Pipeline bat step hangs (after restart)
Title: Message Title Russell Gallop commented on JENKINS-41482 Re: Pipeline bat step hangs (after restart) Note: Still reproducible (though not every time) after update to workflow-api 2.11 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37081) Keep Forever button missing from Pipeline build
Title: Message Title Russell Gallop commented on JENKINS-37081 Re: Keep Forever button missing from Pipeline build Just a note to say this may have just been a problem from our side. If you don't have "discard old builds" enabled then you don't see the "Keep forever" button. With that enabled I see the button on pipeline builds as well (jenkins 2.19.4, pipeline 2.4). Removing my vote but not the original reporter so don't know whether that resolves their issue too. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-39446) Logfilesizechecker plugin support for Pipeline jobs
Title: Message Title Russell Gallop commented on JENKINS-39446 Re: Logfilesizechecker plugin support for Pipeline jobs I'm afraid not. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-40771) Pipeline causes job to hang infinitely on Jenkins restart
Title: Message Title Russell Gallop commented on JENKINS-40771 Re: Pipeline causes job to hang infinitely on Jenkins restart > ...Restart Jenkins as soon as it enters Stage 2, to replicate such behaviour. I'm not sure what Jesse is referring to with "details matter" but please could you say whether you are restarting the master, slave, both? Are the executors on the master node or elsewhere? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41482) Pipeline bat step hangs (after restart)
Title: Message Title Russell Gallop updated an issue Jenkins / JENKINS-41482 Pipeline bat step hangs (after restart) Change By: Russell Gallop Summary: Pipeline bat step hangs (after restart) Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41482) Pipeline bat step hangs
Title: Message Title
Russell Gallop commented on JENKINS-41482
Re: Pipeline bat step hangs
Trying to recreate this on my test Jenkins system (Windows7,jenkins 2.32.1 durable-task 1.13, pipeline 2.4, 1 local executor on master). I'm using:
node() {
bat 'ping 127.0.0.1 -n 50'
echo 'batch completed'
}
and I restart the Windows service while the ping command is running. 3 out of 10 of my runs resulted in a hang so there appears to be a race condition here. Can't be certain but it may be related to system load. When it hangs it has a thread dump like this:
Thread #2
at DSL.bat(awaiting process completion in C:\j\jobs\JENKINS-41482\ws@tmp\durable-82758db8; recurrence period: 6628ms; check task scheduled; cancelled? false done? false)
at WorkflowScript.run(WorkflowScript:2)
at DSL.node(running on )
at WorkflowScript.run(WorkflowScript:1)
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this
[JIRA] (JENKINS-41482) Pipeline bat step hangs
Title: Message Title Russell Gallop updated an issue Jenkins / JENKINS-41482 Pipeline bat step hangs Change By: Russell Gallop Environment: jenkins 2.19.4durable-task 1.12Linux server Windows10 Windows slavejava 1.8.0_51 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41482) Pipeline bat step hangs
Title: Message Title Russell Gallop commented on JENKINS-41482 Re: Pipeline bat step hangs Seen again today. This time the slave was Windows server 2012r2. This time there is no evidence of abnormal termination (e.g. exception) from inside the script but the slave was restarted during the job. There is no message in the console output saying that the job was resuming (would there be?). There is no evidence of the script running on the slave. Maybe this is another resume problem (like JENKINS-33761). The job thread dump is similar: Thread #28 at DSL.bat(awaiting process completion in C:\j\w\\\
[JIRA] (JENKINS-41482) Pipeline bat step hangs
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-41482
Pipeline bat step hangs
Change By:
Russell Gallop
Pipeline jobs occasionally hang on bat steps. This seems similar to JENKINS-34150 but we are using durable-task 1.12 which has the fix for that.Thread dump from the job (after 18 hours):{code}Thread #26 at DSL.bat(awaiting process completion in C:\j\w\\@tmp\durable-56b1eae1 on ) at WorkflowScript.run(WorkflowScript:349) at DSL.withEnv(Native Method) at WorkflowScript.run(WorkflowScript:242) at DSL.stage(Native Method) at WorkflowScript.run(WorkflowScript:156) at DSL.node(running on jagent-win14 ) at WorkflowScript.run(WorkflowScript:34){code}The bat step is running a batch file:{code}cmd /c call test.bat {code}which in turn is running a python script which (in this case) is throwing an exception (I can see from inspecting log files on the slave). Looking on the slave the "durable-56b1eae1" folder is present with jenkins-log.txt, jenkins-main.bat and jenkins-wrap.bat inside of it. There is no sign of the batch process on the slave so I presume that it has completed. The build continues to occupy a slot on the executor. There are also several flyweight tasks from the matrix plugin on the same slave.Please let me know if there is anything else I can do to help diagnose this.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-41482) Pipeline bat step hangs
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-41482
Pipeline bat step hangs
Change By:
Russell Gallop
Pipeline jobs occasionally hang on bat steps. This seems similar to JENKINS-34150 but we are using durable-task 1.12 which has the fix for that.Thread dump from the job (after 18 hours):{code}Thread #26 at DSL.bat(awaiting process completion in C:\j\w\\@tmp\durable-56b1eae1 on ) at WorkflowScript.run(WorkflowScript:349) at DSL.withEnv(Native Method) at WorkflowScript.run(WorkflowScript:242) at DSL.stage(Native Method) at WorkflowScript.run(WorkflowScript:156) at DSL.node(running on jagent-win14) at WorkflowScript.run(WorkflowScript:34){code}The bat step is running a batch file:{code}cmd /c call test.bat {code}which in turn is running a python script which (in this case) is throwing an exception (I can see from inspecting log files on the slave). Looking on the slave the "durable-56b1eae1" folder is present with jenkins-log.txt, jenkins-main.bat and jenkins-wrap.bat inside of it. There is no sign of the batch process on the slave so I presume that it has completed . The build continues to occupy a slot on the executor. There are also several flyweight tasks from the matrix plugin on the same slave.Please let me know if there is anything else I can do to help diagnose this.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-41482) Pipeline bat step hangs
Title: Message Title Russell Gallop created an issue Jenkins / JENKINS-41482 Pipeline bat step hangs Issue Type: Bug Assignee: Unassigned Components: durable-task-plugin, pipeline Created: 2017/Jan/26 3:00 PM Environment: jenkins 2.19.4 durable-task 1.12 Linux server Windows10 slave java 1.8.0_51 Priority: Critical Reporter: Russell Gallop Pipeline jobs occasionally hang on bat steps. This seems similar to JENKINS-34150 but we are using durable-task 1.12 which has the fix for that. Thread dump from the job (after 18 hours): Thread #26 at DSL.bat(awaiting process completion in C:\j\w\\@tmp\durable-56b1eae1 on ) at WorkflowScript.run(WorkflowScript:349) at DSL.withEnv(Native Method) at WorkflowScript.run(WorkflowScript:242) at DSL.stage(Native Method) at WorkflowScript.run(WorkflowScript:156) at DSL.node(running on jagent-win14) at WorkflowScript.run(WorkflowScript:34) The bat step is running a batch file: cmd /c call test.bat which in turn is running a python script which (in this case) is throwing an exception (I can see from inspecting log files on the slave). Looking on the slave the "durable-56b1eae1" folder is present with jenkins-log.txt,
[JIRA] (JENKINS-37081) Keep Forever button missing from Pipeline build
Title: Message Title Russell Gallop commented on JENKINS-37081 Re: Keep Forever button missing from Pipeline build Ping. Is there any update on this issue? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41105) p4sync exceeds pipeline DSL timeout
Title: Message Title Russell Gallop commented on JENKINS-41105 Re: p4sync exceeds pipeline DSL timeout Please re-assign if you think that this is an issue in the pipeline plugin rather than p4. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41105) p4sync exceeds pipeline DSL timeout
Title: Message Title Russell Gallop created an issue Jenkins / JENKINS-41105 p4sync exceeds pipeline DSL timeout Issue Type: Bug Assignee: Unassigned Components: p4-plugin Created: 2017/Jan/16 4:39 PM Environment: p4-plugin 1.4.9 jenkins 2.19.4 Priority: Critical Reporter: Russell Gallop We have a pipeline DSL job which has been working fine for a while but (possibly due to a network outage) started timing out. After timing out for a number of builds however a build hung exceeding its 1 minute timeout. The build was visible on the job page preventing others from running but not in build executor status. We are not able to abort the job despite multiple attempts. There were no obvious p4 threads remaining on the slave. Restarting the slave (which it had run on) did not help so we had to restart the Jenkins master. The last pipeline step from the hanging job was p4sync which reported: P4: Unable to login: com.perforce.p4java.exception.ConnectionException: Unable to resolve Perforce server host name '...' for RPC connection P4: Connection retry: 1 P4: Connection retry giving up... P4: Unable to use Workspace: com.perforce.p4java.exception.ConnectionException: Unable to resolve Perforce server host name '...' for RPC connection P4: Unable to setup workspace: com.perforce.p4java.exception.ConnectionException: Unable to resolve Perforce server host name '...' for RPC connection I don't have a way of reproducing this but have seen it before (also a p4sync). Pipeline DSL
[JIRA] (JENKINS-40055) p4-plugin exception when used with the shared pipeline libraries plugin. p4.tasks.AbstractTask.setEnvironment
Title: Message Title Russell Gallop commented on JENKINS-40055 Re: p4-plugin exception when used with the shared pipeline libraries plugin. p4.tasks.AbstractTask.setEnvironment > The parsing of '@' is a bit fragile, I am aware of '@n' being added for build executors and '@script' added for pipeline scripts, however they may be other uses. I've also seen '@tmp' though I don't know how this is used (and whether it matters for the p4 plugin). Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-40055) p4-plugin exception when used with the shared pipeline libraries plugin. p4.tasks.AbstractTask.setEnvironment
Title: Message Title Russell Gallop edited a comment on JENKINS-40055 Re: p4-plugin exception when used with the shared pipeline libraries plugin. p4.tasks.AbstractTask.setEnvironment > The parsing of '@' is a bit fragile, I am aware of '@n' being added for build executors and '@script' added for pipeline scripts, however they may be other uses.I've also seen '@tmp' though I don't know how this is used ( and or whether it matters for the p4 plugin). Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-39446) Logfilesizechecker plugin support for Pipeline jobs
Title: Message Title Russell Gallop created an issue Jenkins / JENKINS-39446 Logfilesizechecker plugin support for Pipeline jobs Issue Type: Improvement Assignee: Stefan Brausch Components: logfilesizechecker-plugin Created: 2016/Nov/02 3:10 PM Environment: jenkins 2.7.4 logfilesizeplugin 1.2 Labels: pipeline Priority: Minor Reporter: Russell Gallop We find the logfilesizechecker plugin very useful, especially given the issues that you can cause Jenkins with excessive size logs (crashes, slow reloading etc.). It would be very useful if it worked for Pipeline jobs as well. Add Comment
[JIRA] (JENKINS-33761) Ability to disable "resume" build.
Title: Message Title Russell Gallop edited a comment on JENKINS-33761 Re: Ability to disable "resume" build. I'd be happy with resume either working or there being an option to disable it.> I've also never ever seen it work correctly...Likewise but maybe it happens without my noticing :-)> Pipeline does not restart any build steps when Jenkins is restarted. It simply lets the existing process continue running and displaying output (or it might have ended on its own during the Jenkins restart).In the cases where we see resume hanging there is no process running so maybe the problem is with finding the process again, or handling it not being there.Should it handle bat() and sh()? Is the assumption that the slave keeps track of the process output, return value etc.? Will a job always resume to the same slave? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-33761) Ability to disable "resume" build.
Title: Message Title Russell Gallop commented on JENKINS-33761 Re: Ability to disable "resume" build. I'd be happy with resume either working or there being an option to disable it. > I've also never ever seen it work correctly... Likewise but maybe it happens without my noticing > Pipeline does not restart any build steps when Jenkins is restarted. It simply lets the existing process continue running and displaying output (or it might have ended on its own during the Jenkins restart). In the cases where we see resume hanging there is no process running so maybe the problem is with finding the process again, or handling it not being there. Should it handle bat() and sh()? Is the assumption that the slave keeps track of the process output, return value etc.? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38441) Commit notifications stop triggering job after error accessing git server
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-38441
Commit notifications stop triggering job after error accessing git server
Change By:
Russell Gallop
We have a simple pipeline job that checks out source from git (stash) and builds it. This uses "Stash Webhook to Jenkins" commit notifications which should include a SHA1 hash. It generally works fine but occasionally the server will return http code 503 (log below) when checking out. After this, the job stops responding to commit notifications. While we have multiple nodes, this job is only running on one specific node (for performance reasons).Running the job manually gets it out of this state but this should not be necessary. I believe that Jenkins should be resilient to transient failures like this.{ quote code }> git -c core.askpass=true fetch --tags --progress https://stash/product.git +refs/heads/*:refs/remotes/origin/* # timeout=30 > git config --local --remove-section credential # timeout=10ERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException: Failed to fetch from https://stash/product.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:52) at hudson.security.ACL.impersonate(ACL.java:213) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:49) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress https://stash/product.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:stdout: stderr: fatal: unable to access 'https://stash/product.git/': Received HTTP code 503 from proxy after CONNECT at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1740) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1476) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:63) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:314) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at
[JIRA] (JENKINS-38441) Commit notifications stop triggering job after error accessing git server
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-38441
Commit notifications stop triggering job after error accessing git server
Change By:
Russell Gallop
We have a simple pipeline job that checks out source from git (stash) and builds it. This uses "Stash Webhook to Jenkins" commit notifications which should include a SHA1 hash. It generally works fine but occasionally the server will return http code 503 (log below) when checking out. After this, the job stops responding to commit notifications. While we have multiple nodes, this job is only running on one specific node (for performance reasons).Running the job manually gets it out of this state but this should not be necessary. I believe that Jenkins should be resilient to transient failures like this.{quote}> git -c core.askpass=true fetch --tags --progress https://stash/product.git +refs/heads/*:refs/remotes/origin/* # timeout=30 > git config --local --remove-section credential # timeout=10ERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException: Failed to fetch from https://stash/product.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:52) at hudson.security.ACL.impersonate(ACL.java:213) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:49) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress https://stash/product.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:stdout: stderr: fatal: unable to access 'https://stash/product.git/': Received HTTP code 503 from proxy after CONNECT at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1740) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1476) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:63) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:314) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at
[JIRA] (JENKINS-38441) Commit notifications stop triggering job after error accessing git server
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-38441
Commit notifications stop triggering job after error accessing git server
Change By:
Russell Gallop
We have a simple pipeline job that checks out source from git (stash) and builds it. This uses "Stash Webhook to Jenkins" commit notifications which should include a SHA1 hash. It generally works fine but occasionally the server will return http code 503 (log below) when checking out. After this, the job stops responding to commit notifications. While we have multiple nodes, this job is only running on one specific node (for performance reasons).Running the job manually gets it out of this state but this should not be necessary. I believe that Jenkins should be resilient to transient failures like this.{ { quote} > git -c core.askpass=true fetch --tags --progress https://stash/product.git +refs/heads/*:refs/remotes/origin/* # timeout=30 > git config --local --remove-section credential # timeout=10ERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException: Failed to fetch from https://stash/product.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:52) at hudson.security.ACL.impersonate(ACL.java:213) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:49) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress https://stash/product.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:stdout: stderr: fatal: unable to access 'https://stash/product.git/': Received HTTP code 503 from proxy after CONNECT at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1740) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1476) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:63) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:314) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at
[JIRA] (JENKINS-38441) Commit notifications stop triggering job after error accessing git server
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-38441
Commit notifications stop triggering job after error accessing git server
Change By:
Russell Gallop
We have a simple pipeline job that checks out source from git (stash) and builds it. This uses "Stash Webhook to Jenkins" commit notifications which should include a SHA1 hash. It generally works fine but occasionally the server will return http code 503 (log below) when checking out. After this, the job stops responding to commit notifications. While we have multiple nodes, this job is only running on one specific node (for performance reasons).Running the job manually gets it out of this state but this should not be necessary. I believe that Jenkins should be resilient to transient failures like this.{{ > git -c core.askpass=true fetch --tags --progress https://stash/product.git +refs/heads/*:refs/remotes/origin/* # timeout=30 > git config --local --remove-section credential # timeout=10ERROR: Error fetching remote repo 'origin'hudson.plugins.git.GitException: Failed to fetch from https://stash/product.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:52) at hudson.security.ACL.impersonate(ACL.java:213) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:49) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress https://stash/product.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:stdout: stderr: fatal: unable to access 'https://stash/product.git/': Received HTTP code 503 from proxy after CONNECT at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1740) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1476) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:63) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:314) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at
[JIRA] (JENKINS-38441) Commit notifications stop triggering job after error accessing git server
Title: Message Title
Russell Gallop created an issue
Jenkins / JENKINS-38441
Commit notifications stop triggering job after error accessing git server
Issue Type:
Bug
Assignee:
Mark Waite
Components:
git-plugin
Created:
2016/Sep/22 10:57 AM
Environment:
jenkins 2.7.4 git-plugin 2.6.0
Priority:
Major
Reporter:
Russell Gallop
We have a simple pipeline job that checks out source from git (stash) and builds it. This uses "Stash Webhook to Jenkins" commit notifications which should include a SHA1 hash. It generally works fine but occasionally the server will return http code 503 (log below) when checking out. After this, the job stops responding to commit notifications. While we have multiple nodes, this job is only running on one specific node (for performance reasons). Running the job manually gets it out of this state but this should not be necessary. I believe that Jenkins should be resilient to transient failures like this. {{ > git -c core.askpass=true fetch --tags --progress https://stash/product.git +refs/heads/:refs/remotes/origin/ # timeout=30 > git config --local --remove-section credential # timeout=10 ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://stash/product.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:799) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73) at
[JIRA] (JENKINS-36243) ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds
Title: Message Title
Russell Gallop commented on JENKINS-36243
Re: ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds
> If you are not creating these sub-directories, I will need to work out a way to manage them. In the original case, using matrix builds we are not creating the sub-directories so I think we need the plugin to cope with this. From https://github.com/p4paul/p4-jenkins/issues/20 > The Jenkins workspace and Perforce workspace should really be at the same path. We also use git alongside perforce so use dir() { p4sync ...} as a common pattern to keep these separate. To my mind it is cleaner to have perforce checkout to a different directory from git otherwise the git checkout will be inside the perforce workspace. If I ask the p4 plugin to delete generated files then it would remove the git checkout! We also have multiple perforce servers which would be used in some jobs. This would require multiple (perforce) workspaces which I believe would be bad to have in the same directory. Please consider whether it would be possible to support the dir() { p4sync ...} pattern. I don't think that Jenkins workspace and Perforce workspace being the same fits all use cases. dir() { p4sync... } makes it much more flexible and also helps fulfil the promise of Jenkins pipeline DSL being able to truly support multiple SCMs.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[JIRA] (JENKINS-28335) Step to run Git commands w/ credentials & tool (was: GitPublisher support)
Title: Message Title
Russell Gallop commented on JENKINS-28335
Re: Step to run Git commands w/ credentials & tool (was: GitPublisher support)
The workaround published in https://github.com/jenkinsci/pipeline-examples/blob/master/pipeline-examples/push-git-repo/pushGitRepo.Groovy doesn't work with special characters in the password (e.g. @). You can get around that by URL encoding the password:
withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: 'MyID', usernameVariable: 'GIT_USERNAME', passwordVariable: 'GIT_PASSWORD']]) {
String encoded_password = java.net.URLEncoder.encode(env.GIT_PASSWORD, "UTF-8")
sh("git tag -a some_tag -m 'Jenkins'")
sh("git push https://${env.GIT_USERNAME}:${encoded_password}@ --tags")
}
but this defeats the credential binding attempts to obscure the password in the console output. Could do with a proper fix.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-27306) unclassified new org.codehaus.groovy.runtime.GStringImpl java.lang.String java.lang.String[]
Title: Message Title Russell Gallop commented on JENKINS-27306 Re: unclassified new org.codehaus.groovy.runtime.GStringImpl java.lang.String java.lang.String[] Saw this with: org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: unclassified method byte[] encodeBase64 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36243) ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds
Title: Message Title Russell Gallop assigned an issue to Paul Allen Jenkins / JENKINS-36243 ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds Change By: Russell Gallop Assignee: Kohsuke Kawaguchi Paul Allen Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36243) ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-36243
ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds
Change By:
Russell Gallop
Building multiple matrix builds (of one job) at once results in the following exception from the p4 plugin.The job is configured as:Multi-configuration projectExecute concurrent builds if necessary: truep4 scm with a Manual workspace (viewname : " jenkins-$ \ {NODE_NAME \ } \ -$ \ {JOB_NAME \ } ", workspace: " //depot/tool/... //jenkins-$ \ {NODE_NAME \ } \ -$ \ {JOB_NAME \ }/... ") User-defined Axis Name: "FOO" with Values "bar baz"And a single build step executing a Windows batch command: "ping -n 10 127.0.0.1 >nul" to sleep for 10 seconds.Trigger the same job at least twice in quick succession. The first succeeds but the subsequent ones get the above exception.It appears to be a problem when the matrix per-configuration build uses the same node as the flyweight job. This is reproducible with a system with 1 executor on master.{quote}Building on master in workspace C:\jenkins\jobs\matrix_p4_multiple_executions\ws@2\FOO\barFATAL: 1java.lang.ArrayIndexOutOfBoundsException: 1 at org.jenkinsci.plugins.p4.tasks.AbstractTask.setEnvironment(AbstractTask.java:108) at org.jenkinsci.plugins.p4.PerforceScm.checkout(PerforceScm.java:312) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1269) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) at hudson.model.Run.execute(Run.java:1738) at hudson.matrix.MatrixRun.run(MatrixRun.java:146) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410){quote}
Add Comment
[JIRA] (JENKINS-36243) ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-36243
ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds
Change By:
Russell Gallop
Building multiple matrix builds (of one job) at once results in the following exception from the p4 plugin.The job is configured as:Multi-configuration projectExecute concurrent builds if necessary: truep4 scm with a Manual workspace: jenkins-${NODE_NAME}-${JOB_NAME} //depot/tool/... //jenkins-${NODE_NAME}-${JOB_NAME}/...User-defined Axis Name: "FOO" with Values "bar baz"And a single build step executing a Windows batch command: "ping -n 10 127.0.0.1 >nul" to sleep for 10 seconds.Trigger the same job at least twice in quick succession. The first succeeds but the subsequent ones get the above exception.It appears to be a problem when the matrix per-configuration build uses the same node as the flyweight job. This is reproducible with a system with 1 executor on master.{ { quote} Building on master in workspace C:\jenkins\jobs\matrix_p4_multiple_executions\ws@2\FOO\barFATAL: 1java.lang.ArrayIndexOutOfBoundsException: 1 at org.jenkinsci.plugins.p4.tasks.AbstractTask.setEnvironment(AbstractTask.java:108) at org.jenkinsci.plugins.p4.PerforceScm.checkout(PerforceScm.java:312) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1269) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) at hudson.model.Run.execute(Run.java:1738) at hudson.matrix.MatrixRun.run(MatrixRun.java:146) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410) {quote } }
Add Comment
[JIRA] (JENKINS-36243) ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds
Title: Message Title
Russell Gallop created an issue
Jenkins / JENKINS-36243
ArrayIndexOutOfBoundsException with matrix and multiple simultaneous builds
Issue Type:
Bug
Assignee:
Kohsuke Kawaguchi
Components:
matrix-project-plugin, p4-plugin
Created:
2016/Jun/27 2:14 PM
Environment:
jenkins 1.651.3 p4-plugin 1.4.2 matrix-project-plugin 1.7.1
Priority:
Major
Reporter:
Russell Gallop
Building multiple matrix builds (of one job) at once results in the following exception from the p4 plugin. The job is configured as: Multi-configuration project Execute concurrent builds if necessary: true p4 scm with a Manual workspace: jenkins-$ {NODE_NAME}-${JOB_NAME} //depot/tool/... //jenkins-${NODE_NAME} -$ {JOB_NAME} /... User-defined Axis Name: "FOO" with Values "bar baz" And a single build step executing a Windows batch command: "ping -n 10 127.0.0.1 >nul" to sleep for 10 seconds. Trigger the same job at least twice in quick succession. The first succeeds but the subsequent ones get the above exception. It appears to be a problem when the matrix per-configuration build uses the same node as the flyweight job. This is reproducible with a system with 1 executor on master. {{Building on master in workspace C:\jenkins\jobs\matrix_p4_multiple_executions\ws@2\FOO\bar FATAL: 1 java.lang.ArrayIndexOutOfBoundsException: 1 at org.jenkinsci.plugins.p4.tasks.AbstractTask.setEnvironment(AbstractTask.java:108) at org.jenkinsci.plugins.p4.PerforceScm.checkout(PerforceScm.java:312) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1269) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at
[JIRA] [p4-plugin] (JENKINS-29979) Workflow plugin unable to save perforce paramters
Title: Message Title Russell Gallop commented on JENKINS-29979 Re: Workflow plugin unable to save perforce paramters Thanks. Would it be possible to cut a release with this fix in? I think that this justifies it, particularly as the pipeline plugin fix ( JENKINS-28756 ) could stop people creating pipelines jobs from p4 SCM altogether. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [p4-plugin] (JENKINS-29979) Workflow plugin unable to save perforce paramters
Title: Message Title Russell Gallop commented on JENKINS-29979 Re: Workflow plugin unable to save perforce paramters Built from bebc56d8b560728b07edeb3572ccd172c831c5ba and that works for me. It also seems that the snippet generator can now generate a checkout step for p4 (which is good). Is that an expected effect of this change? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [p4-plugin] (JENKINS-33734) P4 Plugin does not reload UI configuration using the Pipeline Workflow
Title: Message Title Russell Gallop commented on JENKINS-33734 Re: P4 Plugin does not reload UI configuration using the Pipeline Workflow I think this is a duplicate of JENKINS-29979. I don't know of a good workaround. I'm using job-dsl-plugin to store jobs in SCM and generate pipeline jobs with embedded scripts. If you accidentally save a job with this configuration then you can just re-run the seed job to get it back. This can get quite unpleasant though as you end up writing pipeline DSL code within Job DSL code. It would be much better if we could use the "Pipeline Script from SCM" option. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-plugin] (JENKINS-34369) NPE on PreBuildMerge.decorateRevisionToBuild
Title: Message Title Russell Gallop commented on JENKINS-34369 Re: NPE on PreBuildMerge.decorateRevisionToBuild I have seen this issue when using the git plugin to merge branches. Git needs to hit a merge conflict (or other error in merging maybe) to hit this problem. Without the pull request (git plugin 2.4.4) > git.exe merge --ff 4f7fc6bad3bc7778104b92950bfc1b3f5e1d3d9d # timeout=10 > git.exe config core.sparsecheckout # timeout=10 > git.exe checkout -f 4f7fc6bad3bc7778104b92950bfc1b3f5e1d3d9d FATAL: null java.lang.NullPointerException at hudson.plugins.git.extensions.impl.PreBuildMerge.decorateRevisionToBuild(PreBuildMerge.java:88) With the pull request applied on top of ce5479a42e74b45dd8b954776ad4220c9c0151bc the problem is reported better. > git.exe merge --ff 4f7fc6bad3bc7778104b92950bfc1b3f5e1d3d9d # timeout=10 > git.exe config core.sparsecheckout # timeout=10 > git.exe checkout -f 4f7fc6bad3bc7778104b92950bfc1b3f5e1d3d9d ERROR: Branch not suitable for integration as it does not merge cleanly: Could not merge AnyObjectId[4f7fc6bad3bc7778104b92950bfc1b3f5e1d3d9d] I think this should have a test case though. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [p4-plugin] (JENKINS-33734) P4 Plugin does not reload UI configuration using the Pipeline Workflow
Title: Message Title Russell Gallop commented on JENKINS-33734 Re: P4 Plugin does not reload UI configuration using the Pipeline Workflow This doesn't seem to be confined to the p4 plugin. When I first create a pipeline job I can choose an SCM from: None CVS CVS Projectset Git Multiple SCMs Perforce Perforce Software Subversion When I return, only the following SCMs are selectable: Git Subversion Is it a coincidence that these are the same 2 that are available in the "checkout: General SCM" step in the snippet generator? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [p4-plugin] (JENKINS-33734) P4 Plugin does not reload UI configuration using the Pipeline Workflow
Title: Message Title Russell Gallop updated an issue Jenkins / JENKINS-33734 P4 Plugin does not reload UI configuration using the Pipeline Workflow I'm not the original reporter but here's a config file from me, with which I see the same symptom. I obfuscated the depot path and the p4_credentials. jenkins 1.642.4 p4 plugin 1.3.8 workflow-aggregator 2.0 Change By: Russell Gallop Attachment: config_ob.xml Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [p4-plugin] (JENKINS-34128) P4 Plugin NODE_NAME is always master for pipeline p4sync step
Title: Message Title
Russell Gallop commented on JENKINS-34128
Re: P4 Plugin NODE_NAME is always master for pipeline p4sync step
As a workaround can use:
p4sync charset: 'none', credential: 'my_creds', depotPath: '//depot/myapp', format: "jenkins-${env.NODE_NAME}-${env.JOB_NAME}"
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [p4-plugin] (JENKINS-33734) P4 Plugin does not reload UI configuration using the Pipeline Workflow
Title: Message Title Russell Gallop commented on JENKINS-33734 Re: P4 Plugin does not reload UI configuration using the Pipeline Workflow I should say I see the same thing. The job appears to work but the UI doesn't reload correctly after initial configuration. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-34174) Jenkins 2.0-rc1 - Getting started hangs installing plugins
Title: Message Title Russell Gallop commented on JENKINS-34174 Re: Jenkins 2.0-rc1 - Getting started hangs installing plugins I wonder if there is a deadlock somewhere in the plugin download code due to higher latency. My ping times to updates.jenkins-ci.org are about 100ms. Is there an option to download plugins sequentially? Or can I specify a mirror with a lower ping? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-34174) Jenkins 2.0-rc1 - Getting started hangs installing plugins
Title: Message Title Russell Gallop updated an issue Jenkins / JENKINS-34174 Jenkins 2.0-rc1 - Getting started hangs installing plugins Tail of log ←[0mApr 12, 2016 4:51:25 PM jenkins.InitReactorRunner$1 onAttained INFO: Started initialization Apr 12, 2016 4:51:25 PM jenkins.InitReactorRunner$1 onAttained INFO: Listed all plugins Apr 12, 2016 4:51:25 PM jenkins.InitReactorRunner$1 onAttained INFO: Prepared all plugins Apr 12, 2016 4:51:25 PM jenkins.InitReactorRunner$1 onAttained INFO: Started all plugins Apr 12, 2016 4:51:25 PM jenkins.InitReactorRunner$1 onAttained INFO: Augmented all extensions Apr 12, 2016 4:51:25 PM jenkins.InitReactorRunner$1 onAttained INFO: Loaded all jobs Apr 12, 2016 4:51:25 PM jenkins.InitReactorRunner$1 onAttained INFO: Completed initialization Apr 12, 2016 4:51:25 PM hudson.ClassicPluginStrategy updateDependency INFO: Updated dependency of matrix-auth Apr 12, 2016 4:51:25 PM hudson.PluginManager dynamicLoad INFO: Plugin cloudbees-folder:5.7 dynamically installed Apr 12, 2016 4:51:25 PM hudson.model.UpdateCenter$DownloadJob run INFO: Installation successful: Folders Plugin Apr 12, 2016 4:51:25 PM hudson.model.UpdateCenter$DownloadJob run INFO: Starting the installation of Credentials Plugin on behalf of admin Apr 12, 2016 4:51:26 PM hudson.model.UpdateCenter$UpdateCenterConfiguration down load INFO: Downloading Credentials Plugin Apr 12, 2016 4:51:27 PM hudson.PluginManager dynamicLoad INFO: Attempting to dynamic load C:\j2\plugins\credentials.jpi Apr 12, 2016 4:51:31 PM jenkins.InitReactorRunner$1 onAttained INFO: Started initialization Apr 12, 2016 4:51:31 PM jenkins.InitReactorRunner$1 onAttained INFO: Listed all plugins Apr 12, 2016 4:51:31 PM jenkins.InitReactorRunner$1 onAttained INFO: Prepared all plugins Apr 12, 2016 4:51:31 PM jenkins.InitReactorRunner$1 onAttained INFO: Started all plugins Apr 12, 2016 4:51:31 PM jenkins.InitReactorRunner$1 onAttained INFO: Augmented all extensions Apr 12, 2016 4:51:31 PM jenkins.InitReactorRunner$1 onAttained INFO: Loaded all jobs Apr 12, 2016 4:51:31 PM jenkins.InitReactorRunner$1 onAttained INFO: Completed initialization Apr 12, 2016 4:51:31 PM hudson.ClassicPluginStrategy updateDependency INFO: Updated dependency of cloudbees-folder Apr 12, 2016 4:51:31 PM hudson.PluginManager dynamicLoad INFO: Plugin credentials:1.27 dynamically installed Apr 12, 2016 4:51:31 PM hudson.model.UpdateCenter$DownloadJob run INFO: Installation successful: Credentials Plugin Apr 12, 2016 4:51:31 PM hudson.model.UpdateCenter$DownloadJob run INFO: Starting the installation of Structs Plugin on behalf of admin Apr 12, 2016 4:51:32 PM hudson.model.UpdateCenter$UpdateCenterConfiguration down load INFO: Downloading Structs Plugin Apr 12, 2016 4:56:42 PM hudson.model.AsyncPeriodicWork$1 run INFO: Started Fingerprint cleanup Apr 12, 2016 4:56:42 PM hudson.model.AsyncPeriodicWork$1 run INFO: Finished Fingerprint cleanup. 2 ms Change By: Russell Gallop
[JIRA] [core] (JENKINS-34174) Jenkins 2.0-rc1 - Getting started hangs installing plugins
Title: Message Title Russell Gallop commented on JENKINS-34174 Re: Jenkins 2.0-rc1 - Getting started hangs installing plugins Okay, I have a script which is successfully downloading plugins from https://updates.jenkins-ci.org/latest/. It has successfully downloaded about 50 and still going. Jenkins seems to have stopped after getting 8. I don't think I've been redirected to a mirror. Tried a different browser (in case the problem is browser side) and get the same thing. I attached a thread dump to the initial report, corresponding to the screenshot. I'll attach threadDump2.txt. This is having downloaded (Ant, OWASP, build timeout, Folders, LDAP, Mailer, Matrix auth and PAM auth). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-34174) Jenkins 2.0-rc1 - Getting started hangs installing plugins
Title: Message Title Russell Gallop commented on JENKINS-34174 Re: Jenkins 2.0-rc1 - Getting started hangs installing plugins > Is your internet connection unstable? I don't have any other problems with it. > While this plugin download is going on, are you able to reach e.g. updates.jenkins-ci.org from the same host? I can reliably ping updates.jenkins-ci.org while it hangs. I did have both wired and wireless network connections enabled but I've just recreated it with just wired. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-34174) Jenkins 2.0-rc1 - Getting started hangs installing plugins
Title: Message Title Russell Gallop created an issue Jenkins / JENKINS-34174 Jenkins 2.0-rc1 - Getting started hangs installing plugins Issue Type: Bug Assignee: Unassigned Attachments: GettingStartedHang.png, threadDump.txt Components: core Created: 2016/Apr/12 2:09 PM Environment: jenkins 2.0-rc1 Windows 7 java version "1.8.0_45" Priority: Major Reporter: Russell Gallop Jenkins 2.0-rc1 hangs for me when installing plugins. I started it with a new jenkins home: set JENKINS_HOME=c:\j2 java -jar jenkins-2.0-rc1.war Copy admin password into localhost:8080 Install suggested plugins Some plugins install, others just sit and spin. I have left if for over an hour. There is an exception in the console: java.lang.InstantiationException:
[JIRA] [core] (JENKINS-32455) Artifacts lost when renaming matrix project with custom Build record directory
Title: Message Title Russell Gallop commented on JENKINS-32455 Re: Artifacts lost when renaming matrix project with custom Build record directory > Try with an instance that doesn't have SCM Sync Configuration and try again. I've disabled SCM Sync (+metadata, multijob, envinject and job config history) and still see the same behaviour (now with 1.642.4). Build 1 was before rename, build 2 is after rename. Log: Apr 12, 2016 11:33:45 AM INFO hudson.model.Run execute JENKINS-32455-testd_renamed/FOO=bar #1 main build action completed: SUCCESS Apr 12, 2016 11:33:46 AM INFO hudson.model.Run execute JENKINS-32455-testd_renamed #1 main build action completed: SUCCESS Apr 12, 2016 11:33:56 AM INFO hudson.model.Run execute JENKINS-32455-testd_renamed/FOO=bar #2 main build action completed: SUCCESS Apr 12, 2016 11:33:57 AM INFO hudson.model.Run execute JENKINS-32455-testd_renamed #2 main build action completed: SUCCESS And these are the resulting files (using git bash on Windows): JENKINS-32455-testd/ JENKINS-32455-testd/FOO=bar/ JENKINS-32455-testd/FOO=bar/builds/ JENKINS-32455-testd/FOO=bar/builds/1/ JENKINS-32455-testd/FOO=bar/builds/1/archive/ JENKINS-32455-testd/FOO=bar/builds/1/archive/afile.txt JENKINS-32455-testd/FOO=bar/builds/1/build.xml JENKINS-32455-testd/FOO=bar/builds/1/changelog.xml JENKINS-32455-testd/FOO=bar/builds/1/log JENKINS-32455-testd/FOO=bar/builds/lastStableBuild JENKINS-32455-testd/FOO=bar/builds/lastSuccessfulBuild JENKINS-32455-testd/FOO=bar/builds/legacyIds JENKINS-32455-testd_renamed/ JENKINS-32455-testd_renamed/builds/ JENKINS-32455-testd_renamed/builds/1/ JENKINS-32455-testd_renamed/builds/1/build.xml JENKINS-32455-testd_renamed/builds/1/changelog.xml JENKINS-32455-testd_renamed/builds/1/log JENKINS-32455-testd_renamed/builds/2/ JENKINS-32455-testd_renamed/builds/2/build.xml JENKINS-32455-testd_renamed/builds/2/changelog.xml JENKINS-32455-testd_renamed/builds/2/log JENKINS-32455-testd_renamed/builds/lastFailedBuild JENKINS-32455-testd_renamed/builds/lastStableBuild JENKINS-32455-testd_renamed/builds/lastSuccessfulBuild JENKINS-32455-testd_renamed/builds/legacyIds JENKINS-32455-testd_renamed/FOO=bar/ JENKINS-32455-testd_renamed/FOO=bar/builds/ JENKINS-32455-testd_renamed/FOO=bar/builds/2/ JENKINS-32455-testd_renamed/FOO=bar/builds/2/archive/ JENKINS-32455-testd_renamed/FOO=bar/builds/2/archive/afile.txt JENKINS-32455-testd_renamed/FOO=bar/builds/2/build.xml JENKINS-32455-testd_renamed/FOO=bar/builds/2/changelog.xml JENKINS-32455-testd_renamed/FOO=bar/builds/2/log JENKINS-32455-testd_renamed/FOO=bar/builds/lastStableBuild JENKINS-32455-testd_renamed/FOO=bar/builds/lastSuccessfulBuild Clarified the original description to say that this was a user-defined axis.
[JIRA] [core] (JENKINS-32455) Artifacts lost when renaming matrix project with custom Build record directory
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-32455
Artifacts lost when renaming matrix project with custom Build record directory
Change By:
Russell Gallop
Using a custom build record directory means that artifacts are lost when renaming a matrix project.I have set up:Build Record Root Directory d:/artifacts/$\{ITEM_FULL_NAME\}/builds/And a matrix job: "Rename_test" which has one user-defined axis "FOO" with one value "bar".which executes a Windows batch command: "echo %BUILD_TAG% > afile.txt"And Archives the artifact afile.txt.I run this a couple of times to create some artifacts then rename the job to "Rename_test_new_name". The artifacts (and other per-configuration build data) are not moved so the folder: d:/artifacts now has "Rename_test" and "Rename_test_new_name". New artifacts are created in the new name, old artifacts are still in the old folder.I think that this may be to do with how ITEM_FULL_NAME works. With the default "Build record root directory" ($\{ITEM_ROOTDIR\}/builds) the per configuration data is stored in:Rename_test/configurations/axis-FOO/bar/buildsWith the build record root directory changed to "d:/artifacts/$\{ITEM_FULL_NAME\}/builds/" they are stored in:Rename_test/FOO=bar/builds
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit
[JIRA] [p4-plugin] (JENKINS-34128) P4 Plugin NODE_NAME is always master for pipeline p4sync step
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-34128
P4 Plugin NODE_NAME is always master for pipeline p4sync step
Change By:
Russell Gallop
{ ${NODE_NAME} } in p4sync format field appears to always say "master".The default workspace name format is { jenkins-${NODE_NAME}-${JOB_NAME} } .e.g. I have a job "MyPipeline" and nodes "master" and "My_node".{code}node ('My_node') {deleteDir()p4sync charset: 'none', credential: 'my_creds', depotPath: '//depot/myapp'bat 'echo %NODE_NAME%'}{code}In the console output you can see that the workspace name always has the node master but the job can access the correct value of NODE_NAME.{code}[Pipeline] Allocate node : StartRunning on My_node in c:\j\w\MyPipeline[Pipeline] node {[Pipeline] deleteDir[Pipeline] p4sync... p4 client -o jenkins-master-MyPipeline +... p4 info +P4 Task: establishing connection server: p4server:1666... node: ... p4 client -o jenkins-master-MyPipeline +... p4 client -i +... client: jenkins-master-MyPipeline... p4 client -o jenkins-master-MyPipeline +... p4 info +... p4 counter change +... p4 changes -m1 -ssubmitted //jenkins-master-MyPipeline/... +Building on Node: master... p4 client -o jenkins-master-MyPipeline +... p4 info +P4 Task: establishing connection server: p4server:1666... node: P4 Task: reverting all pending and shelved revisions p4 revert c:\j\w\MyPipeline/... +... rm [abandoned files]duration: (14ms)P4 Task: cleaning workspace to match have list p4 reconcile -w -f c:\j\w\MyPipeline/... +duration: (79ms)P4 Task: syncing files at change: 1234... p4 sync c:\j\w\MyPipeline/...@1234 +duration: (10ms)P4 Task: saving built changes p4 client -o jenkins-master-MyPipeline +... p4 info +... p4 client -o jenkins-master-MyPipeline +... p4 info +... done[Pipeline] bat[MyPipeline] Running batch scriptc:\j\w\MyPipeline>echo My_node My_node[Pipeline] } //node[Pipeline] Allocate node : End[Pipeline] End of Pipeline{code}Using p4 plugin scm in freestyle jobs works okay.
Add Comment
[JIRA] [p4-plugin] (JENKINS-34128) P4 Plugin NODE_NAME is always master for pipeline p4sync step
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-34128
P4 Plugin NODE_NAME is always master for pipeline p4sync step
Change By:
Russell Gallop
{ $ \ {NODE_NAME \ } } in p4sync format field appears to always say "master".The default workspace name format is {jenkins-${NODE_NAME}-${JOB_NAME}}.e.g. I have a job "MyPipeline" and nodes "master" and "My_node".{code}node ('My_node') {deleteDir()p4sync charset: 'none', credential: 'my_creds', depotPath: '//depot/myapp'bat 'echo %NODE_NAME%'}{code}In the console output you can see that the workspace name always has the node master but the job can access the correct value of NODE_NAME.{code}[Pipeline] Allocate node : StartRunning on My_node in c:\j\w\MyPipeline[Pipeline] node {[Pipeline] deleteDir[Pipeline] p4sync... p4 client -o jenkins-master-MyPipeline +... p4 info +P4 Task: establishing connection server: p4server:1666... node: ... p4 client -o jenkins-master-MyPipeline +... p4 client -i +... client: jenkins-master-MyPipeline... p4 client -o jenkins-master-MyPipeline +... p4 info +... p4 counter change +... p4 changes -m1 -ssubmitted //jenkins-master-MyPipeline/... +Building on Node: master... p4 client -o jenkins-master-MyPipeline +... p4 info +P4 Task: establishing connection server: p4server:1666... node: P4 Task: reverting all pending and shelved revisions p4 revert c:\j\w\MyPipeline/... +... rm [abandoned files]duration: (14ms)P4 Task: cleaning workspace to match have list p4 reconcile -w -f c:\j\w\MyPipeline/... +duration: (79ms)P4 Task: syncing files at change: 1234... p4 sync c:\j\w\MyPipeline/...@1234 +duration: (10ms)P4 Task: saving built changes p4 client -o jenkins-master-MyPipeline +... p4 info +... p4 client -o jenkins-master-MyPipeline +... p4 info +... done[Pipeline] bat[MyPipeline] Running batch scriptc:\j\w\MyPipeline>echo My_node My_node[Pipeline] } //node[Pipeline] Allocate node : End[Pipeline] End of Pipeline{code}Using p4 plugin scm in freestyle jobs works okay.
Add Comment
[JIRA] [p4-plugin] (JENKINS-34128) P4 Plugin NODE_NAME is always master for pipeline p4sync step
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-34128
P4 Plugin NODE_NAME is always master for pipeline p4sync step
Change By:
Russell Gallop
$\{NODE_NAME\} in p4sync format field appears to always say "master".The default workspace name format is { jenkins-$ \ {NODE_NAME \ }-$ \ {JOB_NAME \ } } .e.g. I have a job "MyPipeline" and nodes "master" and "My_node".{code}node ('My_node') {deleteDir()p4sync charset: 'none', credential: 'my_creds', depotPath: '//depot/myapp'bat 'echo %NODE_NAME%'}{code}In the console output you can see that the workspace name always has the node master but the job can access the correct value of NODE_NAME.{code}[Pipeline] Allocate node : StartRunning on My_node in c:\j\w\MyPipeline[Pipeline] node {[Pipeline] deleteDir[Pipeline] p4sync... p4 client -o jenkins-master-MyPipeline +... p4 info +P4 Task: establishing connection server: p4server:1666... node: ... p4 client -o jenkins-master-MyPipeline +... p4 client -i +... client: jenkins-master-MyPipeline... p4 client -o jenkins-master-MyPipeline +... p4 info +... p4 counter change +... p4 changes -m1 -ssubmitted //jenkins-master-MyPipeline/... +Building on Node: master... p4 client -o jenkins-master-MyPipeline +... p4 info +P4 Task: establishing connection server: p4server:1666... node: P4 Task: reverting all pending and shelved revisions p4 revert c:\j\w\MyPipeline/... +... rm [abandoned files]duration: (14ms)P4 Task: cleaning workspace to match have list p4 reconcile -w -f c:\j\w\MyPipeline/... +duration: (79ms)P4 Task: syncing files at change: 1234... p4 sync c:\j\w\MyPipeline/...@1234 +duration: (10ms)P4 Task: saving built changes p4 client -o jenkins-master-MyPipeline +... p4 info +... p4 client -o jenkins-master-MyPipeline +... p4 info +... done[Pipeline] bat[MyPipeline] Running batch scriptc:\j\w\MyPipeline>echo My_node My_node[Pipeline] } //node[Pipeline] Allocate node : End[Pipeline] End of Pipeline{code}Using p4 plugin scm in freestyle jobs works okay.
Add Comment
[JIRA] [p4-plugin] (JENKINS-34128) P4 Plugin NODE_NAME is always master for pipeline p4sync step
Title: Message Title
Russell Gallop created an issue
Jenkins / JENKINS-34128
P4 Plugin NODE_NAME is always master for pipeline p4sync step
Issue Type:
Bug
Assignee:
Unassigned
Components:
p4-plugin
Created:
2016/Apr/08 2:41 PM
Environment:
jenkins 1.642.4 p4-plugin 1.3.8 workflow-aggregator 2.0
Priority:
Major
Reporter:
Russell Gallop
$ {NODE_NAME} in p4sync format field appears to always say "master". The default workspace name format is jenkins-${NODE_NAME}
-$ {JOB_NAME}
.
e.g. I have a job "MyPipeline" and nodes "master" and "My_node".
node ('My_node') {
deleteDir()
p4sync charset: 'none', credential: 'my_creds', depotPath: '//depot/myapp'
bat 'echo %NODE_NAME%'
}
In the console output you can see that the workspace name always has the node master but the job can access the correct value of NODE_NAME.
[JIRA] [pipeline-utility-steps-plugin] (JENKINS-34122) Pipeline-utilities step zip step includes output zip file
Title: Message Title
Russell Gallop created an issue
Jenkins / JENKINS-34122
Pipeline-utilities step zip step includes output zip file
Issue Type:
Bug
Assignee:
rsandell
Components:
pipeline-utility-steps-plugin
Created:
2016/Apr/08 11:36 AM
Environment:
jenkins 1.642.4 pipeline 2.0 pipeline-utility-steps 1.1.4
Priority:
Minor
Reporter:
Russell Gallop
If the zip file that you are creating is in the directory that you are zipping then you get an incomplete version of the output zip inside the archive.
example pipeline DSL.
node {
deleteDir()
touch file: 'afile.txt', timestamp: 0
touch file: 'bfile.txt', timestamp: 0
zip dir: '', glob: '', zipFile: 'thing.zip'
dir ('directory') {
touch file: 'cfile.txt', timestamp: 0
}
v = unzip dir: '', glob: '', read: true, zipFile: 'thing.zip'
println v
}
Console output
Extracting from c:\j\jobs\MyPipeline\ws\thing.zip
Reading:
[JIRA] [p4-plugin] (JENKINS-33734) P4 Plugin does not reload UI configuration using the Pipeline Workflow
Title: Message Title Russell Gallop commented on JENKINS-33734 Re: P4 Plugin does not reload UI configuration using the Pipeline Workflow SETUP.md (https://github.com/jenkinsci/p4-plugin/blob/ebbfc720fcc76cbb98e4fb210c6f7ae1599a57dc/SETUP.md) says "Currently the Groovy CPS DSL from SCM is not supported." so I'm not sure whether this is expected to work. If SETUP.md is out of date then it should be updated. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-32455) Artifacts lost when renaming matrix project with custom Build record directory
Title: Message Title Russell Gallop commented on JENKINS-32455 Re: Artifacts lost when renaming matrix project with custom Build record directory No exception in the log (I've removed messages not related to this job). Build #3 was pre-rename though the log seems to use the new name. (now with jenkins 1.642.2). JENKINS_32455_test_renamed/FOO=bar #3 main build action completed: SUCCESS Mar 15, 2016 9:42:58 AM INFO hudson.model.Run execute JENKINS_32455_test_renamed #3 main build action completed: SUCCESS ... Mar 15, 2016 9:49:38 AM INFO hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness queueChangeSet Queue of changeset A jobs/JENKINS_32455_test/config.xml aborted (scm manipulator not settled !) Mar 15, 2016 9:49:39 AM INFO hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness queueChangeSet Queue of changeset A jobs/JENKINS_32455_test/config.xml aborted (scm manipulator not settled !) Mar 15, 2016 9:49:40 AM INFO hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness queueChangeSet Queue of changeset A jobs/JENKINS_32455_test/config.xml aborted (scm manipulator not settled !) ... Mar 15, 2016 9:53:04 AM INFO hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness queueChangeSet Queue of changeset D jobs/JENKINS_32455_test aborted (scm manipulator not settled !) ... Mar 15, 2016 10:04:41 AM INFO hudson.model.Run execute JENKINS_32455_test_renamed/FOO=bar #4 main build action completed: SUCCESS Mar 15, 2016 10:04:42 AM INFO hudson.model.Run execute JENKINS_32455_test_renamed #4 main build action completed: SUCCESS Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more
[JIRA] [pipeline-stage-view-plugin] (JENKINS-33110) Log details are not shown
Title: Message Title Russell Gallop commented on JENKINS-33110 Re: Log details are not shown Pipeline DSL examples. With 1 step the stage-logs are expanded (but won't contract) e.g.: stage 'test' echo 'Foo' With > 1 step the stage-logs are folded up (and won't expand) e.g.: stage 'test' echo 'Foo' echo 'Bar' Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [pipeline-stage-view-plugin] (JENKINS-33110) Log details are not shown
Title: Message Title Russell Gallop edited a comment on JENKINS-33110 Re: Log details are not shown I also see this issue (workflow-aggregator 1 . 14, pipeline-stage-view 1.0). It seems to work if there is only one step in the stage, just not with more than one. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [pipeline-stage-view-plugin] (JENKINS-33110) Log details are not shown
Title: Message Title Russell Gallop commented on JENKINS-33110 Re: Log details are not shown I also see this issue. It seems to work if there is only one step in the stage, just not with more than one. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [multiple-scms-plugin] (JENKINS-10008) Multi-SCM break Subversion "Repository browser" section
Title: Message Title Russell Gallop commented on JENKINS-10008 Re: Multi-SCM break Subversion "Repository browser" section This doesn't appear to be completely fixed (jenkins 1.642.1/multiple-scms 0.5). When I first enable Multiple SCMs and add a SVN and/or Git SCM then the drop down list is populated. If I leave the configure page and return then the list just shows Auto (maybe that is the same as Daniel Beck was saying above). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [active-directory-plugin] (JENKINS-32623) Incorrect user URL for users with backslashes in name
Title: Message Title Russell Gallop commented on JENKINS-32623 Re: Incorrect user URL for users with backslashes in name The "Started by user" message on the build page is not correctly escaped. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-32805) Poll SCM Schedule form validation is wrong for @hourly, @daily
Title: Message Title Russell Gallop created an issue Jenkins / JENKINS-32805 Poll SCM Schedule form validation is wrong for @hourly, @daily Issue Type: Bug Assignee: Unassigned Attachments: PollSCMScheduleValidation.PNG Components: core Created: 05/Feb/16 3:18 PM Environment: jenkins 1.642.1 Priority: Minor Reporter: Russell Gallop After entering a schedule such as @hourly or @daily in the "Poll SCM" (SCMTrigger) field the form validation reports when it would have last run and will next run. The times that it reports however appear to be different from the times that the SCM is actually polled. The times for "Build Periodically" (TimerTrigger) appear to be correct. I have created a job called "TestCron" and that shows different times for Poll SCM and Build Periodically (see screenshot). It appears to me that these should both be the same as they are based on the hash of the item name.
[JIRA] [core] (JENKINS-32805) Poll SCM Schedule form validation is wrong for @hourly, @daily
Title: Message Title
Russell Gallop edited a comment on JENKINS-32805
Re: Poll SCM Schedule form validation is wrong for @hourly, @daily
In TimerTrigger.java the check is implemented by:{code}public FormValidation doCheckSpec(@QueryParameter String value, @AncestorInPath Item item) {try {CronTabList ctl = CronTabList.create(fixNull(value), item != null ? Hash.from(item.getFullName()) : null);{code}which I guess is finding the name of the item in the URL for the hash.It looks like "Build Periodically" is using the checkUrl: { { http:///job/TestCron/descriptorByName/hudson.triggers.TimerTrigger/checkSpec?value=%40daily} } but "Poll SCM" is using { { http:///trigger/TimerTrigger/check?value=%40daily} } .So Poll SCM is probably unable to find the item name in the URL so initialises the hash with null and generates the previous and next times for that. This matches up with the fact that changing the job name affects the periodic schedule but not the SCM schedule (which is 0 apart from the seconds).
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-32805) Poll SCM Schedule form validation is wrong for @hourly, @daily
Title: Message Title
Russell Gallop commented on JENKINS-32805
Re: Poll SCM Schedule form validation is wrong for @hourly, @daily
In TimerTrigger.java the check is implemented by:
public FormValidation doCheckSpec(@QueryParameter String value, @AncestorInPath Item item) {
try {
CronTabList ctl = CronTabList.create(fixNull(value), item != null ? Hash.from(item.getFullName()) : null);
which I guess is finding the name of the item in the URL for the hash.
It looks like "Build Periodically" is using the checkUrl: {http:///job/TestCron/descriptorByName/hudson.triggers.TimerTrigger/checkSpec?value=%40daily}
but "Poll SCM" is using {http:///trigger/TimerTrigger/check?value=%40daily}
.
So Poll SCM is probably unable to find the item name in the URL so initialises the hash with null and generates the previous and next times for that. This matches up with the fact that changing the job name affects the periodic schedule but not the SCM schedule (which is 0 apart from the seconds).
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [active-directory-plugin] (JENKINS-32623) Incorrect user URL for users with backslashes in name
Title: Message Title Russell Gallop commented on JENKINS-32623 Re: Incorrect user URL for users with backslashes in name I notice that the asynchPeople page correctly escapes the url to: user/domain%5Cuser Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [active-directory-plugin] (JENKINS-32623) Incorrect user URL for users with backslashes in name
Title: Message Title Russell Gallop commented on JENKINS-32623 Re: Incorrect user URL for users with backslashes in name Note the page source appears to have a backslash: "model-link inside inverse" href="" class="code-quote" style="color: #009100">"/user/DOMAIN\user">User Name Chrome (48.0.2564.82 64-bit) and IE (11.0.9600.18163) seem to "fix" this to be a slash. Firefox (43.0.1) doesn't fix it so works okay. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [active-directory-plugin] (JENKINS-32623) Incorrect user URL for users with backslashes in name
Title: Message Title Russell Gallop created an issue Jenkins / JENKINS-32623 Incorrect user URL for users with backslashes in name Issue Type: Bug Assignee: Unassigned Components: active-directory-plugin, core Created: 26/Jan/16 1:11 PM Environment: jenkins 1.609.2 active-directory 1.41 Priority: Minor Reporter: Russell Gallop We authenticate with an Active Directory Forest and users log in with names such as "DOMAIN\user". When logged in the link to their user area in the top right is something like: http:///user/DOMAIN/user which gives a 404 error when clicked. Replacing the slash with an escape code http:///user/DOMAIN%2Fuser or http:///user/DOMAIN%5Cuser or using an underscore http:///user/DOMAIN_user works. The link to the users account should probably use one of these. I am not sure whether this is a problem in Jenkins core or the active directory plugin.
[JIRA] [core] (JENKINS-32455) Artifacts lost when renaming matrix project with custom Build record directory
Title: Message Title
Russell Gallop created an issue
Jenkins / JENKINS-32455
Artifacts lost when renaming matrix project with custom Build record directory
Issue Type:
Bug
Assignee:
Kohsuke Kawaguchi
Components:
core, matrix-project-plugin
Created:
14/Jan/16 3:05 PM
Environment:
1.625.1
Priority:
Major
Reporter:
Russell Gallop
Using a custom build record directory means that artifacts are lost when renaming a matrix project.
I have set up: Build Record Root Directory d:/artifacts/$ {ITEM_FULL_NAME}/builds/ And a matrix job: "Rename_test" which has one axis "FOO" with one value "bar". which executes a Windows batch command: "echo %BUILD_TAG% > afile.txt" And Archives the artifact afile.txt. I run this a couple of times to create some artifacts then rename the job to "Rename_test_new_name". The artifacts (and other per-configuration build data) are not moved so the folder: d:/artifacts now has "Rename_test" and "Rename_test_new_name". New artifacts are created in the new name, old artifacts are still in the old folder. I think that this may be to do with how ITEM_FULL_NAME works. With the default "Build record root directory" (${ITEM_ROOTDIR}/builds) the per configuration data is stored in: Rename_test/configurations/axis-FOO/bar/builds With the build record root directory changed to "d:/artifacts/${ITEM_FULL_NAME}
[JIRA] [core] (JENKINS-32455) Artifacts lost when renaming matrix project with custom Build record directory
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-32455
Artifacts lost when renaming matrix project with custom Build record directory
Change By:
Russell Gallop
Using a custom build record directory means that artifacts are lost when renaming a matrix project.I have set up:Build Record Root Directory d:/artifacts/$\{ITEM_FULL_NAME\}/builds/And a matrix job: "Rename_test" which has one axis "FOO" with one value "bar".which executes a Windows batch command: "echo %BUILD_TAG% > afile.txt"And Archives the artifact afile.txt.I run this a couple of times to create some artifacts then rename the job to "Rename_test_new_name". The artifacts (and other per-configuration build data) are not moved so the folder: d:/artifacts now has "Rename_test" and "Rename_test_new_name". New artifacts are created in the new name, old artifacts are still in the old folder.I think that this may be to do with how ITEM_FULL_NAME works. With the default "Build record root directory" ($ \ {ITEM_ROOTDIR \ }/builds) the per configuration data is stored in:Rename_test/configurations/axis-FOO/bar/buildsWith the build record root directory changed to "d:/artifacts/$ \ {ITEM_FULL_NAME \ }/builds/" they are stored in:Rename_test/FOO=bar/builds
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit
[JIRA] [core] (JENKINS-32455) Artifacts lost when renaming matrix project with custom Build record directory
Title: Message Title
Russell Gallop updated an issue
Jenkins / JENKINS-32455
Artifacts lost when renaming matrix project with custom Build record directory
Change By:
Russell Gallop
Using a custom build record directory means that artifacts are lost when renaming a matrix project.I have set up:Build Record Root Directory d:/artifacts/$ \ {ITEM_FULL_NAME \ }/builds/And a matrix job: "Rename_test" which has one axis "FOO" with one value "bar".which executes a Windows batch command: "echo %BUILD_TAG% > afile.txt"And Archives the artifact afile.txt.I run this a couple of times to create some artifacts then rename the job to "Rename_test_new_name". The artifacts (and other per-configuration build data) are not moved so the folder: d:/artifacts now has "Rename_test" and "Rename_test_new_name". New artifacts are created in the new name, old artifacts are still in the old folder.I think that this may be to do with how ITEM_FULL_NAME works. With the default "Build record root directory" (${ITEM_ROOTDIR}/builds) the per configuration data is stored in:Rename_test/configurations/axis-FOO/bar/buildsWith the build record root directory changed to "d:/artifacts/${ITEM_FULL_NAME}/builds/" they are stored in:Rename_test/FOO=bar/builds
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit
[JIRA] [job-dsl-plugin] (JENKINS-32391) Add support for Perforce p4 plugin
Title: Message Title Russell Gallop created an issue Jenkins / JENKINS-32391 Add support for Perforce p4 plugin Issue Type: New Feature Assignee: Daniel Spilker Components: job-dsl-plugin Created: 11/Jan/16 3:22 PM Labels: job-dsl p4-plugin Priority: Minor Reporter: Russell Gallop Plugin: https://wiki.jenkins-ci.org/display/JENKINS/P4+Plugin The Job DSL Plugin support the "Perforce Plugin" but not the "P4 Plugin". The "P4 Plugin" has the distinct advantage of working with credentials. For my requirements "Manual (Custom view)" is the only Workspace behaviour required. This would be a good starting point for supporting this plugin. Unfortunately the perforce plugin support is already using the DSL syntax p4. Support for the p4 plugin could use the term perforce instead. e.g. perforce(String credentials, String workspace_name, String viewspec, Closure configure = null)
[JIRA] [email-ext-plugin] (JENKINS-32131) Job DSL Plugin extended email pre-send script does not have same default as UI
Title: Message Title
Russell Gallop created an issue
Jenkins / JENKINS-32131
Job DSL Plugin extended email pre-send script does not have same default as UI
Issue Type:
Bug
Assignee:
Daniel Spilker
Components:
email-ext-plugin, job-dsl-plugin
Created:
17/Dec/15 4:51 PM
Environment:
jenkins 1.625.1 job-dsl-plugin 1.40 email-ext 2.40.5
Priority:
Minor
Reporter:
Russell Gallop
CONTRIBUTING.md (DSL Design) states that "Every option should have the same defaults as the UI". This is not the case for the extended email plugin.
When creating an extended email publisher with Job DSL:
job('example') {
publishers {
extendedEmail('m...@halfempty.org', 'Oops', 'Something broken')
}
}
Pre-send script (under Advanced settings) is left blank.
After creating an "Editable email notification" from the UI the default is: $DEFAULT_PRESEND_SCRIPT
This makes it very easy to create jobs which don't use the system specified script. I can add this using a configure block but
[JIRA] [job-dsl-plugin] (JENKINS-31308) Creating folder removes existing views within that
Title: Message Title Russell Gallop commented on JENKINS-31308 Re: Creating folder removes existing views within that Thanks for all of the suggestions. My idea is that the top level seed shouldn't have to know about all of the jobs and the per-folder seeds create the jobs and add them to views explicitly. So one option would be to have all of the seeds at the top level (seed, seed_folder1, seed_folder2). seed would create seed_folder1/2 etc. then they would be responsible for creating the folders, jobs and views. The downside of this is that you can't take advantage of per folder lookup strategy, all jobs would have to have full names. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [job-dsl-plugin] (JENKINS-31308) Creating folder removes existing views within that
Title: Message Title Russell Gallop commented on JENKINS-31308 Re: Creating folder removes existing views within that Thanks for the info. Is there a way of checking if the folder exists from Job DSL code? I can't see one. Of course avoiding creating the folder means that changes to displayName or description will not be picked up. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
