[JIRA] (JENKINS-49332) Jenkins unable to manage webhooks of Github organization
Title: Message Title
magnayn commented on JENKINS-49332
Re: Jenkins unable to manage webhooks of Github organization
I don't know if this is of help, and it's a bit embarrasing that the most common usecase ("I have a github org, I want to build all the projects, and have webhooks added so this is efficient/fast") is so terrible UX-wise. But: In the project configuration, top level (github organization), you need to set up the organisation name (so it finds the right projects). You need some credentials to access github. It only lists "username/password" items on the list. However : for github if you're using a personal access token, the username is irrelevant. It really should offer 'secret' types in this list. I got ours to work by (re)creating a username/password credentials as username = ORG_NAME, password = personal_access_token. This might be of help.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.188195.151753948.8417.1558516200985%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-35184) Failed to load jenkins.util.SystemProperties on slaves due to ServletContext
Title: Message Title magnayn commented on JENKINS-35184 Re: Failed to load jenkins.util.SystemProperties on slaves due to ServletContext So I'm seeing this in mvn hpi:run but not in running the jenkins war. doing dependency:tree on the plugin shows this: [INFO] +- javax.servlet:javax.servlet-api:jar:3.1.0:test [INFO] +- javax.servlet:servlet-api:jar:2.4:provided So it looks like both are being included 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-35184) Failed to load jenkins.util.SystemProperties on slaves due to ServletContext
Title: Message Title magnayn updated an issue Jenkins / JENKINS-35184 Failed to load jenkins.util.SystemProperties on slaves due to ServletContext Change By: magnayn Priority: Critical Blocker 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-35184) Failed to load jenkins.util.SystemProperties on slaves due to ServletContext
Title: Message Title magnayn commented on JENKINS-35184 Re: Failed to load jenkins.util.SystemProperties on slaves due to ServletContext I have this error too (Jenkins 2.7) Slave is evargas/jenkins-slave docker image (1.7.0_101), master is 1.8. [09/10/16 16:52:18] [SSH] Starting slave process: cd "/home/jenkins" && java -jar slave.jar <===[JENKINS REMOTING CAPACITY]===>channel started Slave.jar version: 2.59 This is a Unix agent java.io.IOException: Remote call on docker-cb0efbf57eef failed at hudson.remoting.Channel.call(Channel.java:789) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:536) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:381) at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:901) at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:126) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:658) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:642) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.LinkageError: Failed to load jenkins.util.SystemProperties at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:342) at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:251) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at hudson.util.RingBufferLogHandler.(RingBufferLogHandler.java:39) at hudson.slaves.SlaveComputer$LogHolder.(SlaveComputer.java:799) at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:808) at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:802) at hudson.remoting.UserRequest.perform(UserRequest.java:152) at hudson.remoting.UserRequest.perform(UserRequest.java:50) at hudson.remoting.Request$2.run(Request.java:332) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) 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) at ..remote call to docker-cb0efbf57eef(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416) at hudson.remoting.UserResponse.retrieve(UserRequest.java:252) at hudson.remoting.Channel.call(Channel.java:781) ... 10 more Caused by: java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:803) at java.lang.ClassLoader.defineClass(ClassLoader.java:643) at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:338) at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:251) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at hudson.util.RingBufferLogHandler.(RingBufferLogHandler.java:39) at hudson.slaves.SlaveComputer$LogHolder.(SlaveComputer.java:799) at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:808) at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:802) at hudson.remoting.UserRequest.perform(UserRequest.java:152) at hudson.remoting.UserRequest.perform(UserRequest.java:50) at hudson.remoting.Request$2.run(Request.java:332) at
[JIRA] (JENKINS-36080) docker 1.12 breaks plugin because of HostConfig
Title: Message Title magnayn commented on JENKINS-36080 Re: docker 1.12 breaks plugin because of HostConfig So in the jenkinsci/docker-plugin there is a docker-java-next branch, which targets the changed 3.x docker-java API I also have a fork of docker-java (magnayn/docker-java) that contains necessary patches for some parts that I suspect will take a long time to get upstreamed. If you want to hack a fix to docker-java, we can include it in the forked repo in lieu of an upstream fix. I also suspect being able to specify the API version as a configuration element would indeed be useful and ought not to have been removed (I have to do this on the commandline for some hosts). 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-36080) docker 1.12 breaks plugin because of HostConfig
Title: Message Title magnayn commented on JENKINS-36080 Re: docker 1.12 breaks plugin because of HostConfig See https://github.com/docker-java/docker-java/issues/617 If you want to fix this, you'll probably have to a) Get the above fixed in docker-java b) Migrate all of jenkins-docker to use docker-java's 3.x API (as 2.x is "discontinued due to lack of resources") c) Ensure 3.x (or fork thereof) includes something equivalent to https://github.com/docker-java/docker-java/pull/610 None of these are likely hard ( (b) is a touch fiddly, I tried once but backed out when I had no available time). Good luck! 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] [remoting] (JENKINS-20947) Failed to monitor for Free Swap Space
Title: Message Title
magnayn commented on JENKINS-20947
Re: Failed to monitor for Free Swap Space
I have just come across this on two types of host.
First on Illumos(Smartos)/LX zones, it occasionally reports gigantic free memory (probably a bug), after which the buld log stops updating
{{Failed to monitor Triton-455640a8f44f for Free Swap Space java.util.concurrent.ExecutionException: java.io.IOException: Failed to parse: '18446744073709099244' out of 'MemFree: 18446744073709099244 kB' at hudson.remoting.Channel$2.adapt(Channel.java:813) at hudson.remoting.Channel$2.adapt(Channel.java:808) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitor(AbstractAsyncNodeMonitorDescriptor.java:96) at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:305) Caused by: java.io.IOException: Failed to parse: '18446744073709099244' out of 'MemFree: 18446744073709099244 kB' at org.jvnet.hudson.ProcMemInfo.monitor(ProcMemInfo.java:56) at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:113) at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:103) at hudson.remoting.UserRequest.perform(UserRequest.java:120) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at ..remote call to Triton-455640a8f44f(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416) at hudson.remoting.UserResponse.retrieve(UserRequest.java:220) at hudson.remoting.Channel$2.adapt(Channel.java:811) ... 4 more}}
I also now get this on Jenkins 2.x on windows slaves:
Failed to monitor winbuild for Free Swap Space java.util.concurrent.ExecutionException: java.lang.UnsatisfiedLinkError: C:\Users\magnayn\AppData\Local\Temp\jna-829177819\jna2657881109746216710.dll: A dynamic link library (DLL) initialization routine failed at hudson.remoting.Channel$2.adapt(Channel.java:813) at hudson.remoting.Channel$2.adapt(Channel.java:808) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitor(AbstractAsyncNodeMonitorDescriptor.java:96) at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:305) Caused by: java.lang.UnsatisfiedLinkError: C:\Users\magnayn\AppData\Local\Temp\jna-829177819\jna2657881109746216710.dll: A dynamic link library (DLL) initialization routine failed at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.load0(Unknown Source) at java.lang.System.load(Unknown Source) at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:851) at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:826) at com.sun.jna.Native.(Native.java:140) at com.sun.jna.Pointer.(Pointer.java:41) at com.sun.jna.Structure.(Structure.java:2078) at org.jvnet.hudson.Windows.monitor(Windows.java:42) at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:113) at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:103) at hudson.remoting.UserRequest.perform(UserRequest.java:120) at
[JIRA] [github-branch-source-plugin] (JENKINS-34120) Do not suppress unmergeable PRs
Title: Message Title magnayn commented on JENKINS-34120 Re: Do not suppress unmergeable PRs When I looked in github, as far as it was concerned it was still mergeable; the only check that had failed (and the only one we use) was the Jenkins build. 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] [github-branch-source-plugin] (JENKINS-34120) PRs that fail builds immediately disappear from the build list
Title: Message Title
magnayn created an issue
Jenkins / JENKINS-34120
PRs that fail builds immediately disappear from the build list
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
github-branch-source-plugin, workflow-plugin
Created:
2016/Apr/08 10:42 AM
Priority:
Critical
Reporter:
magnayn
If I create a PR in github, the build automatically gets created.
However, if it fails, the next branch indexing log (which happened just after) does this:
{{ Getting remote pull requests...
Checking pull request #PR-4 Not mergeable, skipping}}
This removes the build entirely - so one cannot find out why it failed.
Incidentally, the "Not mergeable" isn't correct - it is mergeable, it's just Jenkins has reported a check-failure against it.
Add Comment
[JIRA] [durable-task-plugin] (JENKINS-34119) Shell process killed (OOM), but pipeline continues anyway
Title: Message Title magnayn created an issue Jenkins / JENKINS-34119 Shell process killed (OOM), but pipeline continues anyway Issue Type: Bug Assignee: Jesse Glick Components: durable-task-plugin Created: 2016/Apr/08 10:01 AM Environment: linux Priority: Major Reporter: magnayn I have a jenkins pipeline, that invokes mvn with a 'sh mvn ' invocation. Occasionally, the output shows the maven execution suddenly stop, and the pipeline continuing anyway (failing later because the maven part hadn't actually completed). I haven't been able to confirm, but my strong suspicion is mvn has been killed by the linux OOM killer. Digging in SO, when processes are killed in this way, the 'return code' alone isn't valid. (http://stackoverflow.com/questions/7180970/return-code-when-oom-killer-kills-a-process). I'm not sure the best way to figure this out, as of course bash is calling a script (mvn) which is in turn calling java (the actual maven process that'd be the one being killed).
[JIRA] [docker-plugin] (JENKINS-31475) Docker plugin does not provision containers for builds with multiple labels
Title: Message Title magnayn commented on JENKINS-31475 Re: Docker plugin does not provision containers for builds with multiple labels Not sure that's a docker-plugin issue - the machinery for node labelling is core to Jenkins. The important bit to check is DockerCloud getTemplates(Label label) - this is where it'll figure out if there is any matching template for launching. 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] [docker-plugin] (JENKINS-31397) Docker plugin does not provision container
Title: Message Title magnayn commented on JENKINS-31397 Re: Docker plugin does not provision container INFO: Not Provisioning 'evarga/jenkins-slave'; Server 'api-docker' full with '1' container(s) Your cloud is overprovisioned. You need to increase the max no. of containers it's allowed to run. 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] [workflow-plugin] (JENKINS-30798) Workflow multibranch failed after rebase: IllegalStateException: could not find branch tip
Title: Message Title
magnayn edited a comment on JENKINS-30798
Re: Workflow multibranch failed after rebase: IllegalStateException: could not find branch tip
I would - but - since I applied a name-correction-hack (below) to multi-branch-workflow and restarting I haven't seen the problem since.. ;-/ {{ @@ -42,11 +42,14 @@ public class WorkflowBranchProjectFactory extends BranchProjectFactory
[JIRA] [workflow-plugin] (JENKINS-30798) Workflow multibranch failed after rebase: IllegalStateException: could not find branch tip
Title: Message Title
magnayn commented on JENKINS-30798
Re: Workflow multibranch failed after rebase: IllegalStateException: could not find branch tip
I would - but - since I applied a name-correction-hack (below) to multi-branch-workflow and restarting I haven't seen the problem since.. ;-/
{{@@ -42,11 +42,14 @@ public class WorkflowBranchProjectFactory extends BranchProjectFactory
[JIRA] [docker-plugin] (JENKINS-23301) Support unix protocol for connection
Title: Message Title magnayn resolved as Fixed Should now allow also containers on the same host without port mapping. Jenkins / JENKINS-23301 Support unix protocol for connection Change By: magnayn Status: Open Resolved Assignee: Kanstantsin Shautsou magnayn Resolution: Fixed 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] [workflow-plugin] (JENKINS-30798) workflow multibranch failed after rebase
Title: Message Title magnayn commented on JENKINS-30798 Re: workflow multibranch failed after rebase Rather helpfully (for me, or unhelpfully for debugging) when I re-started the instance, the 404s went away and it started behaving as normal. :-/ The original issue also went away - so it looks like some transient issue where manipulating what branches get build and/or rebasing one of them causes a failure that restarting recovers from. I will keep monitoring and try to find out if there's a trigger cause. 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] [workflow-plugin] (JENKINS-30798) workflow multibranch failed after rebase
Title: Message Title magnayn commented on JENKINS-30798 Re: workflow multibranch failed after rebase Hm. Even more strange behaviour. I'd set the 'branches' to be "dev*, release*" - which doesn't work. So I changed it to "dev* release*" - and then when I thought a bit more to just "*". Now I have projects building - but I can't access their URL. E.g: http://jenkins.blah.com/job/rd2/ Shows a list of branches. But clicking on one (e.g: dev-main) that's currently building goes to http://jenkins.blah.com/job/rd2/branch/dev-main/ Which results in a 404 Not Found. 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] [workflow-plugin] (JENKINS-30798) workflow multibranch failed after rebase
Title: Message Title
magnayn created an issue
Jenkins / JENKINS-30798
workflow multibranch failed after rebase
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
workflow-plugin
Created:
05/Oct/15 1:53 PM
Labels:
multibranch workflow
Priority:
Minor
Reporter:
magnayn
I rebased a branch (dev/main) in git, but the workflow-multibranch poller didn't seem to pick it up.
When I retriggered, I got the following error
Started by user anonymous
java.lang.IllegalStateException: could not find branch tip on SCMHead{'dev/main'}
at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:91)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:183)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Finished: FAILURE
[JIRA] [workflow-plugin] (JENKINS-30798) workflow multibranch failed after rebase
Title: Message Title magnayn commented on JENKINS-30798 Re: workflow multibranch failed after rebase Not sure. I may have also seen this behaviour in the non-wf multi branch, where branches seem to have just stopped building. I also tried re-running the branch indexing, but didn't seem to help 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] [workflow-plugin] (JENKINS-30252) Provide easy access to git branch name in multibranch workflow scripts
Title: Message Title
magnayn commented on JENKINS-30252
Re: Provide easy access to git branch name in multibranch workflow scripts
Ah. That explains why my workflow produces nulls in
{{
node('docker') {
checkout scm;
echo "Build of $ {env.GIT_COMMIT}
on $ {env.GIT_BRANCH}
";
// etc etc }}
Seems like SCM passing environment vars is going to be pretty important?
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] [workflow-plugin] (JENKINS-30252) Provide easy access to git branch name in multibranch workflow scripts
Title: Message Title
magnayn edited a comment on JENKINS-30252
Re: Provide easy access to git branch name in multibranch workflow scripts
Ah. That explains why my workflow produces nulls in { { code:java} node('docker') {checkout scm; echo "Build of ${env.GIT_COMMIT} on ${env.GIT_BRANCH}"; // etc etc {code } } Seems like SCM passing environment vars is going to be pretty important?
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] [workflow-plugin] (JENKINS-30744) multibranch issues if branch contains /
Title: Message Title magnayn commented on JENKINS-30744 Re: multibranch issues if branch contains / My fix didn't seem to work for me (but I haven't investigated too closely to figure out why that may be - it might be I need to re-create the project from scratch). It occurred to me that maybe the correct place to fix was in Branch (something like branch.getSafeName() or similar). 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] [workflow-plugin] (JENKINS-30744) multibranch issues if branch contains /
Title: Message Title magnayn edited a comment on JENKINS-30744 Re: multibranch issues if branch contains / My Correction - fix didn't seem to did work for me ( , but I haven't investigated too closely had to figure out why that may be - it might be I need to re-create the project from scratch) . I'll see if it works (I get other oddities with projects with %2F in them, like maven fails in really weird places!) It occurred to me that maybe the correct place to fix was in Branch (something like branch.getSafeName() or similar) . but I was unsure of the implications of the project name != branch 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] [core] (JENKINS-21487) Frozen UI
magnayn reopened JENKINS-21487 Frozen UI Change By: magnayn (13/Aug/14 8:17 AM) Resolution: CannotReproduce Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-21487) Frozen UI
magnayn commented on JENKINS-21487 Frozen UI So, I'm re-opening this as I can re-create the "white screen of death" regularly on our Jenkins instance, on the latest LTS (1.565.1). I think this is strongly influenced by slow(ish) disk (we are ZFS on Linux), because it's often sitting relatively low levels of CPU. We have a reasonable number of jobs, but nothing to write home about. Running the groovy script from above seems to show it spending extreme amounts of time in what looks like parsing XML files. To get the size, it's triggering the following bit of trace: at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:234) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read(BufferedInputStream.java:265) locked 0xf9b461f0 (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:83) at java.io.PushbackInputStream.read(PushbackInputStream.java:139) at com.thoughtworks.xstream.core.util.XmlHeaderAwareReader.getHeader(XmlHeaderAwareReader.java:79) at com.thoughtworks.xstream.core.util.XmlHeaderAwareReader.init(XmlHeaderAwareReader.java:61) at com.thoughtworks.xstream.io.xml.AbstractXppDriver.createReader(AbstractXppDriver.java:65) at hudson.XmlFile.unmarshal(XmlFile.java:163) at hudson.model.Run.reload(Run.java:321) at hudson.model.Run.init(Run.java:309) at hudson.model.AbstractBuild.init(AbstractBuild.java:173) at hudson.maven.AbstractMavenBuild.init(AbstractMavenBuild.java:54) at hudson.maven.MavenModuleSetBuild.init(MavenModuleSetBuild.java:146) at sun.reflect.GeneratedConstructorAccessor58.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at jenkins.model.lazy.LazyBuildMixIn.loadBuild(LazyBuildMixIn.java:153) at jenkins.model.lazy.LazyBuildMixIn$1.create(LazyBuildMixIn.java:134) at hudson.model.RunMap.retrieve(RunMap.java:218) at hudson.model.RunMap.retrieve(RunMap.java:56) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:687) locked 0x82951908 (a hudson.model.RunMap) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:670) at jenkins.model.lazy.AbstractLazyLoadRunMap.getById(AbstractLazyLoadRunMap.java:542) at jenkins.model.lazy.BuildReferenceMapAdapter.unwrap(BuildReferenceMapAdapter.java:42) at jenkins.model.lazy.BuildReferenceMapAdapter.access$200(BuildReferenceMapAdapter.java:27) at jenkins.model.lazy.BuildReferenceMapAdapter$SetAdapter._unwrap(BuildReferenceMapAdapter.java:356) at jenkins.model.lazy.BuildReferenceMapAdapter$SetAdapter.access$400(BuildReferenceMapAdapter.java:248) at jenkins.model.lazy.BuildReferenceMapAdapter$SetAdapter$1.adapt(BuildReferenceMapAdapter.java:271) at jenkins.model.lazy.BuildReferenceMapAdapter$SetAdapter$1.adapt(BuildReferenceMapAdapter.java:269) at hudson.util.AdaptedIterator.next(AdaptedIterator.java:54) at com.google.common.collect.Iterators$7.computeNext(Iterators.java:648) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at java.util.Collections$UnmodifiableCollection$1.hasNext(Collections.java:1101) at java.util.AbstractMap$2$1.hasNext(AbstractMap.java:392) at hudson.util.RunList.size(RunList.java:108) That seems really, really expensive to perform when all the caller cares about is the size of the runlist. Regardless of anything else, that looks like an easy optimisation. Similarly, the home page lockups seem to be because it spends a long time figuring out "what was the last successful / last failed" build, which looks to be similar in nature. I wonder if that could be cached to speed it up without having to load the entire dataset. It's possible that it's memory pressure causing the system to dump this stuff and it having to reload. I'm going to try increasing Xmx and maybe getting some dumps to figure out what's happening. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more
[JIRA] [core] (JENKINS-21487) Frozen UI
magnayn resolved JENKINS-21487 as Fixed Frozen UI Change By: magnayn (13/Aug/14 11:24 AM) Status: Reopened Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-21487) Frozen UI
magnayn commented on JENKINS-21487 Frozen UI I think it is still an issue, but the issue is much bigger (I.E: it's dumb parsing thousands of files to render a simple UI homepage). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23442) Jenkins 1.568 can not start when monitoring plugin is installed
magnayn reopened JENKINS-23442 Jenkins 1.568 can not start when monitoring plugin is installed Same issue. Only thing I can think of - our Jenkins uses JDK8. Change By: magnayn (12/Aug/14 10:10 PM) Resolution: CannotReproduce Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [port-allocator] (JENKINS-18908) Port Allocator v1.6 serializes all builds
magnayn
created JENKINS-18908
Port Allocator v1.6 serializes all builds
Issue Type:
Bug
Assignee:
ramapulavarthi
Components:
port-allocator
Created:
24/Jul/13 2:59 PM
Description:
We upgraded Port allocator (and lots of other things), and found the strange and unexpected behaviour that our builds seemed not to be running correctly on slaves.
After much digging, the finger points to the upgrade of port allocator.
The following groovy script shows why:
def q = Jenkins.getInstance().getQueue();
q.getClass().getDeclaredFields().each() { it-println "$it.name"; }
def fld = ResourceController.class.getDeclaredField("inUse");
fld.setAccessible(true);
def result = fld.get(q);
def fld2 = ResourceList.class.getDeclaredField("all");
fld2.setAccessible(true);
result.each() {
def result2 = fld2.get(it);
result2.each() { res - println "... ${res.class}"; }
}
Gives
...
... class hudson.model.Resource
... class hudson.model.Resource
Result: {standalone port SHUTDOWN_PORT(1)=W1, standalone port HTTP_PORT(1)=W1}
The first build through is blocking every other build, which just sits there for multiple hours until complete. Since they are on entirely different slaves (computers), this is particularly wrong.
We had to downgrade to 1.5 to fix this.
Project:
Jenkins
Priority:
Major
Reporter:
magnayn
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-18909) Provide a UI way to determine why a build is waiting
magnayn created JENKINS-18909 Provide a UI way to determine why a build is waiting Issue Type: Improvement Assignee: Unassigned Components: core Created: 24/Jul/13 3:02 PM Description: Whilst diagnosing JENKINS-18908, I had to delve into reflecting out the contents of Jenkins.getInstance().getQueue(). That's quite hard to do unless you fire up Groovy console. It would be very useful to be able to see, in the UI, why a build is stuck in the ResourceController, what it's waiting for, c. Without the digging it looked very much like an environment / ssh / bug in Jenkins, but in reality it was just an errant plugin.. Project: Jenkins Priority: Major Reporter: magnayn This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-18682) Strange NoClassDefFoundError on slave with flexible-publish
magnayn created JENKINS-18682 Strange NoClassDefFoundError on slave with flexible-publish Issue Type: Bug Assignee: bap Components: core, flexible-publish Created: 09/Jul/13 9:22 PM Description: At the end of the job: Waiting for Jenkins to finish collecting data channel stopped Run condition Always enabling perform for step Archive the artifacts Archiving artifacts ERROR: Failed to archive artifacts: */.log hudson.util.IOException2: java.lang.NoClassDefFoundError: Could not initialize class jnr.posix.POSIXFactory at hudson.FilePath.copyRecursiveTo(FilePath.java:1943) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:137) at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110) at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154) at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105) at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:88) at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:96) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776) at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:969) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726) at hudson.model.Run.execute(Run.java:1618) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:491) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:242) Caused by: java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: Could not initialize class jnr.posix.POSIXFactory at hudson.remoting.Channel$4.adapt(Channel.java:755) at hudson.remoting.Channel$4.adapt(Channel.java:750) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55) at hudson.FilePath.copyRecursiveTo(FilePath.java:1941) ... 15 more Caused by: java.lang.NoClassDefFoundError: Could not initialize class jnr.posix.POSIXFactory at hudson.os.PosixAPI.jnr(PosixAPI.java:30) at hudson.util.IOUtils.mode(IOUtils.java:125) at hudson.util.io.TarArchiver.visit(TarArchiver.java:102) at hudson.util.DirScanner$Glob.scan(DirScanner.java:133) at hudson.FilePath.writeToTar(FilePath.java:1979) at hudson.FilePath.access$1000(FilePath.java:169) at hudson.FilePath$36.invoke(FilePath.java:1920) at hudson.FilePath$36.invoke(FilePath.java:1916) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2388) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Build step 'Flexible publish' changed build result to FAILURE Finished: FAILURE Environment: Jenkins Project: Jenkins Priority: Major Reporter: magnayn
[JIRA] [git] (JENKINS-17763) Git plugin clean workspace blows away private maven repository
magnayn created JENKINS-17763 Git plugin clean workspace blows away private maven repository Issue Type: Bug Assignee: Nicolas De Loof Components: git Created: 27/Apr/13 11:01 AM Description: When you select "Clean repository workspace", this executes the equivalent of 'git -fdx' in $WORKSPACE If you have 'local maven repository' selected, then there is a maven repo in $WORKSPACE/.repository. So this option deletes the whole repo, which is not what is wanted. I'm not sure what the most reasonable fix is, though. Clearly 'git -fdx -e .repository' will probably work, but it's a bit... 'magic' Project: Jenkins Priority: Major Reporter: magnayn This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
