[JIRA] (JENKINS-27299) Refactor Disable Build feature out of AbstractProject for Pipeline Compatibility
Title: Message Title Matthew Mitchell commented on JENKINS-27299 Re: Refactor Disable Build feature out of AbstractProject for Pipeline Compatibility I feel like this should be a higher priority. This makes using pipeline in conjunction with job dsl difficult. 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-42158) Allow for multiple declarative pipelines in a single file
Title: Message Title Matthew Mitchell commented on JENKINS-42158 Re: Allow for multiple declarative pipelines in a single file Even better would be if the Multibranch pipelines allowed for specifying a pattern by which declarative pipeline files could be picked up. This would allow interesting scenarios like being able to alter triggers and add new pipeline files in a single PR. 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-42158) Allow for multiple declarative pipelines in a single file
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-42158 Allow for multiple declarative pipelines in a single file Issue Type: Improvement Assignee: Andrew Bayer Components: pipeline-model-definition-plugin Created: 2017/Feb/17 7:12 PM Labels: pipeline Priority: Major Reporter: Matthew Mitchell It would be fantastic to somehow allow a single Jenkinsfile with the declarative pipeline model to have multiple pipelines in it (today this appears to work somewhat). This would mean you could define independent units of work in a single file and not rely on some external mechanism. This would also allow for separate sets of triggers for each section of the pipeline. This would mean scenarios like: 1) Run this pipeline nightly, but this pipeline daily 2) Trigger this scenario on X comment on GitHub, but this other scenario on Y Would be possible. We have huge matrices of testing and need to be able to select the workload Add Comment
[JIRA] (JENKINS-40488) Extend support for all Azure regions
Title: Message Title Matthew Mitchell commented on JENKINS-40488 Re: Extend support for all Azure regions Also it should dynamically get the list of available sizes 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-41379) Cannot provision Windows agent
Title: Message Title Matthew Mitchell commented on JENKINS-41379 Re: Cannot provision Windows agent This got resolved. The VM sizes are incorrect in the plugin currently (for some sizes) 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-41379) Cannot provision Windows agent
Title: Message Title Matthew Mitchell commented on JENKINS-41379 Re: Cannot provision Windows agent Can you check the acitivty log or deployment info in the Azure portal? It's quite possible you're hitting some kind of subscription limit or such. 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-40620) disable associate publicIP address
Title: Message Title Matthew Mitchell commented on JENKINS-40620 Re: disable associate publicIP address This has become a bigger issue as our installation has increased in size. 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-40488) Extend support for all Azure regions
Title: Message Title Matthew Mitchell commented on JENKINS-40488 Re: Extend support for all Azure regions To do this the plugin needs to dynamically get the list of regions. 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-41381) Allow for passing of secrets to startup scripts
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-41381 Allow for passing of secrets to startup scripts Issue Type: Improvement Assignee: Claudiu Guiman Components: azure-vm-agents-plugin Created: 2017/Jan/24 5:29 PM Priority: Minor Reporter: Matthew Mitchell It would be great to be able to pass secrets to the VM startups scripts. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40934) Poor performance queuing large parallel workloads
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-40934 Poor performance queuing large parallel workloads Issue Type: Bug Assignee: Unassigned Attachments: slowbranches.txt Components: workflow-cps-plugin Created: 2017/Jan/10 4:48 AM Priority: Major Reporter: Matthew Mitchell When the number of parallel branches in pipeline increases a lot, the performance of the pipeline decreases significantly. There appears to be an n^2 algorithm somewhere. ~200 branches - okay 4k branches - glacial Attached is a stack trace taken while the behavior was exibited. I'm pretty sure this ends up n^2: "Running CpsFlowExecution[Ownercorex_full/54:corex_full #54]" Id=421 Group=main RUNNABLE at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.getCurrentHeads(CpsFlowExecution.java:703) locked org.jenkinsci.plugins.workflow.cps.CpsFlowExecution@6ebdc0a3 at org.jenkinsci.plugins.workflow.support.actions.LogActionImpl.isRunning(LogActionImpl.java:152) at org.jenkinsci.plugins.workflow.support.actions.LogActionImpl.access$000(LogActionImpl.java:66) at org.jenkinsci.plugins.workflow.support.actions.LogActionImpl$1.onNewHead(LogActionImpl.java:93) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.notifyListeners(CpsFlowExecution.java:1081) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.notifyNewHead(CpsThreadGroup.java:381) at org.jenkinsci.plugins.workflow.cps.FlowHead.setNewHead(FlowHead.java:119) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:171) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:126) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108)
[JIRA] (JENKINS-39835) Be super defensive in remoting read
Title: Message Title Matthew Mitchell commented on JENKINS-39835 Re: Be super defensive in remoting read Alright, so I root caused most of this. While there certainly are issues around the error handling, the errors we saw are all caused by memory. As we begin to run out of memory, the finally blocks that should zero out the channel object never get called. This causes a sort of cascading failure the manifests in a number of ways, including the error message above. The number of threads jumps, reflection starts to hang (job dsl starts to fail), etc. For my instance, the root cause was the workspace cleanup plugin + node recycling. This was keeping channel objects around forever in some cases, causing a slow leak. I would first verify that memory isn't the cause of the failure. I do the following: Watch number of threads: watch -n1 'find /proc//task -maxdepth 1 -type d -print | wc -l' Watch gc stats: jstat -gccause -t -h25 10s If the number of threads starts to jump into the high-thousands (depending on your heap setup) then that's a good indication. jstat will show failure to allocate eventually, and a high number of full gcs. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. This also appears to perhaps happen "near" a failure https://issues.jenkins-ci.org/browse/JENKINS-33358 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. Right, for sure. I think there are a few cases: 1) Cases where plugins/core usae computer.getChannel(). These work fine since if the listeners run properly, the channel is set to null and the code can do the right thing at that point depending on what its function is. 2) Cases where the channel object is held on an object (Ping thread, etc.) but there is error handling. These appear okay (ping thread exits). 3) Cases where the channel object is held on an object but no error handling - These need fixing. I don't know of any real cases of #3. #2 appears okay. #1 is a problem because the listeners which should null out the channel on the computer object don't actually run. That is why we see the "already connected" 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. Yep, that correlates with what I've seen too. What is odd about this is that the actual usage doesn't appear that large. A heap dump before the failure doesn't show a heap that is anywhere close to full (3GB usage of 32GB). But I do see lots of "unable to allocate new native thread", etc and the number of threads grows very large from the steady state. Could this be related to a deadlock of some sort where we start to spawn threads till we die? 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. Do you use Job DSL too? I think there might be something there that is related too. Based on the data seen, I think this may be a deadlock. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. FYI when this problem occurs the number of threads starts to climb from steady state at ~800-1500 up to 11k. Most of the extra threads look like they are doing nothing (just a single frame on a thread named Thread-NN). 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. Also, this Issue looks extremely close to what I am seeing. Perhaps there is a lock on the channel object? https://issues.jenkins-ci.org/browse/JENKINS-5413 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. I added a bunch more logging to the system to see why the channel would not get cleared out. I've got another couple pieces of info: For me, there seems to be some relation to Job DSL execution. Not exactly sure why. There's definitely something memory related, as we see a big jump in memory usage when this happens, and there are for sure some allocation failures. However, the overall heap usage is actually really low (compared to avialable size), so it might be the GC telling us unable to allocate. When the error happens, I see the following sequence. 1. Timeout failures monitoring for clock difference, disk space, etc. on the node. 2. Ping failure on the node. 3. already connected to this master. Now, some other things to note. I added logging to the listeners on the channel set up that would close the channel and null out the reference on the Computer object (onClosed). However, for the affected nodes, the onClosed methods are never executed, so the listeners never get run. Why that is, is the big mystery. 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"
[JIRA] (JENKINS-5055) server rejected connection: already connected to master
Title: Message Title Matthew Mitchell commented on JENKINS-5055 Re: server rejected connection: already connected to master Woops I was wondering where this comment went. Was supposed to go to another issue. And yes. It doesn't have anything to do with the ping rate. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. Some more info. While I think the "already connected to this master" is a real bug, I think the way that it's triggered might be considered expected. I see this when the number of threads in the system suddenly spikes. This seems to cause some cascading failures (maybe "Unable to allocate new native thread")? In our instance, this might be caused by the Build Failure Analyzer, which can use a lot of threads. I do know some other things: 1) Raising the java heap size reduces the amount of memory for native threads and potentially seems to reduce the time to repro. 2) Allocating a ton of new threads very fast seems to cause this. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. So I think the "already connected" may be caused by a cycle in the closing logic. Though I don't know why the error keeps propping up. It looks like the channel pinger could cause a channel close to happen. Under the jnlp remoting, we set up a channel with an onClose listener, which itself tries to close the channel under certain circumstances. These listeners are run in the channel termination finally logic, so it's possible that we could try to close while we are already under the close operations. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. hudson.remoting.ChannelClosedException: channel is already closed at hudson.remoting.Channel.send(Channel.java:578) at hudson.remoting.Request.callAsync(Request.java:205) at hudson.remoting.Channel.callAsync(Channel.java:807) at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitor(AbstractAsyncNodeMonitorDescriptor.java:75) at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:305) Caused by: java.io.IOException at hudson.remoting.Channel.close(Channel.java:1163) at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:123) at hudson.remoting.PingThread.ping(PingThread.java:126) at hudson.remoting.PingThread.run(PingThread.java:85) Caused by: java.util.concurrent.TimeoutException: Ping started at 1479165919577 hasn't completed by 1479166819577 ... 2 more 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-5055) server rejected connection: already connected to master
Title: Message Title Matthew Mitchell commented on JENKINS-5055 Re: server rejected connection: already connected to master I have some other data (Jenkins 6.42.1 running on Ubuntu 16.04 Java 8). This only happens on nodes that were connected via jnlp by running a command on the node (java -jar ...) and is not limited to Windows. Seen on OSX too. The failure is always preceded by: INFO: Ping failed. Terminating the channel The ping fails for many machines within a few seconds. Only those machines connected via manual jnlp remoting call fail ping In the server we have running, the nodes running that don't fail are connected via ssh and are Linux, FreeBSD, etc. The nodes that fail and don't fail exist in the same locations (VMs in Azure) So the interesting data point here I think is the fact that the ping doesn't fail on the machines connected via SSH channel. Is it that they aren't using the JNLP remoting protocol? 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
[JIRA] (JENKINS-23271) Intermittent Invalid Object ID in remoting module
Title: Message Title Matthew Mitchell commented on JENKINS-23271 Re: Intermittent Invalid Object ID in remoting module So the proposed fix isn't the correct one? 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] [core] (JENKINS-34888) Too much string concatenation in unmarshalling code
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-34888 Too much string concatenation in unmarshalling code Issue Type: Bug Assignee: Unassigned Components: core Created: 2016/May/17 3:35 PM Priority: Minor Reporter: Matthew Mitchell In the RobustReflectionConverter, there is a bit of code concatenating strings based on field and class and checking for them in a set (critical fields). The number of critical fields is very low, but the number of fields to check is very high, so we end up doing a LOT of string concatentation for no purpose at all. Add Comment
[JIRA] [core] (JENKINS-34887) PingFailureAnalyzer NPE
Title: Message Title Matthew Mitchell commented on JENKINS-34887 Re: PingFailureAnalyzer NPE Perf for this has been improved as part of https://github.com/jenkinsci/jenkins/pull/2340 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-34887) PingFailureAnalyzer NPE
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-34887 PingFailureAnalyzer NPE Issue Type: Bug Assignee: Unassigned Components: core Created: 2016/May/17 3:30 PM Priority: Minor Reporter: Matthew Mitchell I've seen this a few times in the past: Exception in thread "Ping thread for channel hudson.remoting.Channel@63b204d9:channel" java.lang.NullPointerException at jenkins.slaves.PingFailureAnalyzer.all(PingFailureAnalyzer.java:31) at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:111) at hudson.remoting.PingThread.ping(PingThread.java:126) at hudson.remoting.PingThread.run(PingThread.java:85) Mar 29, 2016 12:05:10 PM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:82) at hudson.remoting.ChunkedInputStream.readHeader(ChunkedInputStream.java:72) at hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:103) at hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:39) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at
[JIRA] [core] (JENKINS-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. Alright, I was unable to get an exact repo, but I think I saw enough, plus combined with the logs, to figure out what happens: 1) The PingFailureAnalyzer call in onDead in ChannelPinger.java will occasionally fail for various reasons. NPE's, findClass failures. Not always, but sometimes. When this happens, the master will NOT call close on the channel. 2) Normally this appears to be fine. The channel is somehow replaced or null'd out through other means. I think in cases of process termination or other semi-orderly shutdowns the socket connection is notified. 3) However, let's say there is a network anomoly. Power outage, network cable unplugged, dropped connection not on the server/client side. In this case, the master will notice, potentially by noticing a failed ping. If it fails in the PingFailureAnalyzer code, it won't close the channel. 4) The slave comes back, say from a reboot, or the network cable is reinstalled, etc. and attempts to reconnect. The channel is not null, and we get the error. I think the keys to the repro are the lack of a "Terminate" text in the slave log and the definite issue of not closing the channel when an exception is seen in the PFA. The lack of terminate indicates there was not an orderly shutdown of the channel on the client side. So, the fix would be to wrap the call to the PFA in a try catch to ensure that channel.close() is in fact called. The issues I was seeing in my installation have subsided, but this fix was made as they were tailing off, and I think I did not see any already connected errors after that. 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
[JIRA] [core] (JENKINS-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. I'm trying to set up a fake repro for this where the client will always fail and attempt to close the channel to see whether I can get the master to have the same issue seen in the wild. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. The Launcher code in remoting (that has all the client side options, also launches a pinger. So I think there is a pinger from both sides, but not the exact same code) 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. So I think what's going on is that certain kind of network outages (or maybe a reboot) are causing issues with the master realizing that the connection is closed. I think I see one place where there is a bug: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/slaves/ChannelPinger.java#L111 I've seen the call into the PingFailureAnalyzer return NPE, causing us to miss the call to terminate the channel. However, unless I'm misunderstanding the code, I think that's executing on the client, which wouldn't cause the server to keep the channel open. Do you have any special ping setting set on Jenkins startup? 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. Douglass, do you know anything more about the intallations where we are seeing this? I think I am seeing a pattern in my repros that has to do with slave deletion (and maybe creation). I think for us this correlates with increased usage of the azure cloud plugin Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. I got a full thread dump channelclosedstack.txt while this was happening and am invstigating, since for whatever reason this is hitting us full bore right now. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell updated an issue Jenkins / JENKINS-28492 The server rejected the connection: *** is already connected to this master. Rejecting this connection. Change By: Matthew Mitchell Attachment: channelclosedstack.txt 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell edited a comment on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. Also, we didn't use it see this at all, but there appears to be a large uptick in instances since moving towards more cloud allocated machines (azure-slave-plugin) though the Azure slave plugin machine do not ever see the issue. I have also never seen it on SSH connected machines. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. Also, we didn't use it see this at all, but there appears to be a large uptick in instances since moving towards more cloud allocated machines (azure-slave-plugin) though the Azure slave plugin machine do not ever see the issue. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell edited a comment on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. I'm also seeing this on Jenkins 1.642. 1 3 . In addition, if the connection is explicitly stopped on the slave side, the master still shows the slave as connected. 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-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title Matthew Mitchell commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. I'm also seeing this on Jenkins 1.642.1. In addition, if the connection is explicitly stopped on the slave side, the master still shows the slave as connected. 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-33704) Multiple calls to the CloudRetentionStrategy when removing a node
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-33704 Multiple calls to the CloudRetentionStrategy when removing a node Issue Type: Bug Assignee: Unassigned Attachments: stack.txt Components: core Created: 2016/Mar/21 8:56 PM Priority: Major Reporter: Matthew Mitchell If a node has a cloud retention strategy, calling removeNode will execute the cloud retention strategy. This could cause further node removal and further loops in the call chain. Since the queue is locked, if node removal is expensive, then Jenkins can potentially appear down while the node removal is happening. Version 1.642.1 Add Comment
[JIRA] [core] (JENKINS-23244) Slave build history page has no data and spawns a ton of very long-lived blocking threads on the master
Title: Message Title Matthew Mitchell commented on JENKINS-23244 Re: Slave build history page has no data and spawns a ton of very long-lived blocking threads on the master (FYI this installation is around 6-7k builds a day) Even in the case of walking newer builds, it seems like this woudl be super expensive. Maybe it's better to keep an index of buildname/number to machine to avoid loading the metadata at all? 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-23244) Slave build history page has no data and spawns a ton of very long-lived blocking threads on the master
Title: Message Title Matthew Mitchell commented on JENKINS-23244 Re: Slave build history page has no data and spawns a ton of very long-lived blocking threads on the master I'm seeing this in our installation. It severely impacts the repsonsiveness of the system. 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-32818) Jenkins stops responding to web HTTP requests
Title: Message Title Matthew Mitchell commented on JENKINS-32818 Re: Jenkins stops responding to web HTTP requests I am guessing no. That's the normal state for our instance, which uses a lot of build flow jobs. Those are just waiting around for other builds to complete so that they can either complete the build flow job, or queue a new dependent job. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell commented on JENKINS-32371 Re: Excessive wait times to clear build/node assocation after job completes Saw this again, but in low GC pressure situation. See stack trace here. dotnet_corefx/nativecomp_ubuntu_release_prtest build 1848 spent around 20 mins waiting to finish 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-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell updated an issue Jenkins / JENKINS-32371 Excessive wait times to clear build/node assocation after job completes Change By: Matthew Mitchell Attachment: jenkins-job-ending-hang.txt 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-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title
Matthew Mitchell commented on JENKINS-32371
Re: Excessive wait times to clear build/node assocation after job completes
This code from the LogRotator looks pretty suspect (line 150). The initial call to size() as well as copy itself will iterate the list. I'm not quite sure what the solution here is, but avoiding the loading of all the builds is probably important. I wonder if you could almost just estimate the number of builds kept around based on some cached initial build number (lowest known build number) and the maximum build number. It wouldn't be exact, but it would be fast.
if(artifactNumToKeep!=null && artifactNumToKeep!=-1) { List> builds = job.getBuilds(); for (Run r : copy(builds.subList(Math.min(builds.size(), artifactNumToKeep), builds.size( { if (shouldKeepRun(r, lsb, lstb)) { continue; }
LOGGER.log(FINE, " {0}
is to be purged of artifacts", r); r.deleteArtifacts(); } }
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-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell edited a comment on JENKINS-32371 Re: Excessive wait times to clear build/node assocation after job completes Saw this again, but in low GC pressure situation. See stack trace here. dotnet_corefx/nativecomp_ubuntu_release_prtest build 1848 spent around 20 mins waiting to finish [^jenkins-job-ending-hang.txt] 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-32818) Jenkins stops responding to web HTTP requests
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-32818 Jenkins stops responding to web HTTP requests Issue Type: Bug Assignee: Unassigned Attachments: jenkins-hang.txt Components: core Created: 05/Feb/16 10:18 PM Priority: Critical Reporter: Matthew Mitchell Seen twice now, Jenkins stops responding to web HTTP requests. Oddly enough,the pull request builder and build build nodes still appear to be doing thing in the background, Github gets status updates, etc. However the webiste cannot be accessed. See stack trace. GC does not appear to be an issue. Only using about 40% of available heap space not over the max perm gen. Add Comment
[JIRA] [core] (JENKINS-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell commented on JENKINS-32371 Re: Excessive wait times to clear build/node assocation after job completes This seems to have mostly been resolved, though i still see it occasionally under heavy load, even when a GC is not happening. 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-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell commented on JENKINS-32371 Re: Excessive wait times to clear build/node assocation after job completes This instance was sitting around with a 16GB allocated heap (standard GC type). What might be the typical heap size used for a large Jenkins instance? Is it possible there is a major mem leak somewhere? 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-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell commented on JENKINS-32371 Re: Excessive wait times to clear build/node assocation after job completes It seems like it might some kind of modified sawtooth based on my watching of the proc mem usage. Sawtooth with a gradual creeping upward of the lower bound. I have a heap dump, though it was captured without -live (for reasons of taking too long). Does that help? I took a bit of a look at it and noticed a ton of strings related to the EnvInject plugin (which I think is default, right?). I then looked at the plugin source and it maintains a non-transient reference to the parent build. I was under the impression that in general it's bad to maintain that kind of pointer on actions since it prevents collection. Anyways, since I wasn't looking at live it could be something else. Some other thoughts: Switching to the G1 collector? 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-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell commented on JENKINS-32371 Re: Excessive wait times to clear build/node assocation after job completes I think this also seems to occur only when the queue is long (> 100) I'm a little suspicious it is related to the throttle concurrent builds plugin. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell commented on JENKINS-32371 Re: Excessive wait times to clear build/node assocation after job completes Added a thread dump. dci-cnt71-bld-4 is the executor that was still showing execution while the build was showing 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 options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell updated an issue Jenkins / JENKINS-32371 Excessive wait times to clear build/node assocation after job completes Thread dump Change By: Matthew Mitchell Attachment: threaddump.txt 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-32371) Excessive wait times to clear build/node assocation after job completes
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-32371 Excessive wait times to clear build/node assocation after job completes Issue Type: Bug Assignee: Unassigned Components: core Created: 08/Jan/16 8:12 PM Environment: Seen in the dotnet-ci.cloudapp.net installation (1.643) Priority: Major Reporter: Matthew Mitchell After upgrading to the latest Jenkins (though I'm not sure this wasn't seen before), version 1.643, after running for a while I will see a wait between when a job is finished (reports success/failure) and when the node appears to stop executing the job. This also appears to affect the build flow plugin, where a build will not report as finished. The wait can be as low as a couple minutes but frequently is near 20-30 mins.
[JIRA] [ghprb-plugin] (JENKINS-32013) Inefficient trigger code when there is a large number of jobs/PR triggers in Jenkins
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-32013 Inefficient trigger code when there is a large number of jobs/PR triggers in Jenkins Issue Type: Bug Assignee: Honza Brázdil Components: ghprb-plugin Created: 10/Dec/15 6:10 PM Priority: Minor Reporter: Matthew Mitchell In large Jenkins installations with large numbers of jobs and pull request triggers, the doIndex code ends up being fairly inefficient for processing the github pull request messages. For each type of message, the entire project list is walked and a new GhprbWebHook object is allocated (twice in cases where it is actually needed). As the number of projects in our instance has grown, it more and more time to trigger each build. Add Comment
[JIRA] [git-plugin] (JENKINS-31586) NPE When using submodules extension
Title: Message Title Matthew Mitchell created an issue Jenkins / JENKINS-31586 NPE When using submodules extension Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 16/Nov/15 10:12 PM Priority: Minor Reporter: Matthew Mitchell Seen this when submodules are selected. I think this happens when the build settings change and we get a first time build. 12:51:26 First time build. Skipping changelog. 12:51:26 FATAL: null 12:51:26 java.lang.NullPointerException 12:51:26 at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:82) 12:51:26 at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1074) 12:51:26 at hudson.scm.SCM.checkout(SCM.java:485) 12:51:26 at hudson.model.AbstractProject.checkout(AbstractProject.java:1276) 12:51:26 at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607) 12:51:26 at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) 12:51:26 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) 12:51:26 at hudson.model.Run.execute(Run.java:1738) 12:51:26 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 12:51:26 at hudson.model.ResourceController.execute(ResourceController.java:98) 12:51:26 at hudson.model.Executor.run(Executor.java:410)
[JIRA] [build-flow-plugin] (JENKINS-25664) Caused by link does not work for 4 digit build numbers (above thousand)
Title: Message Title Matthew Mitchell assigned an issue to Matthew Mitchell Jenkins / JENKINS-25664 Caused by link does not work for 4 digit build numbers (above thousand) Change By: Matthew Mitchell Assignee: NicolasDeLoof MatthewMitchell Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-flow-plugin] (JENKINS-25664) Caused by link does not work for 4 digit build numbers (above thousand)
Title: Message Title Matthew Mitchell commented on JENKINS-25664 Re: Caused by link does not work for 4 digit build numbers (above thousand) Fixed in PR https://github.com/jenkinsci/build-flow-plugin/pull/62 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-flow-plugin] (JENKINS-25664) Caused by link does not work for 4 digit build numbers (above thousand)
Title: Message Title Matthew Mitchell started work on JENKINS-25664 Change By: Matthew Mitchell Status: Open InProgress 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] [htmlpublisher-plugin] (JENKINS-25328) HTML Publisher - HTTP 404 - The requested resource is not available
Matthew Mitchell commented on JENKINS-25328 HTML Publisher - HTTP 404 - The requested resource is not available That was more of a "is this known"... I'm seeing the archive happen correctly: config.xml: http://dotnet-ci.cloudapp.net/job/dotnet_corefx_coverage_windows/config.xml (Let me know if you can't access this) Link: http://dotnet-ci.cloudapp.net/job/dotnet_corefx_coverage_windows/lastSuccessfulBuild/Code_Coverage_Report/ Last successful build listing (abbreviated) **@dotnet-ci:/var/lib/jenkins/jobs/dotnet_corefx_coverage_windows/builds/lastSuccessfulBuild/htmlreports/Code_Coverage_Report$ ls combined.js System.Reflection.Metadata_MethodSemanticsTableReader.htm htmlpublisher-wrapper.htmlSystem.Reflection.Metadata_MethodSpecificationHandle.htm index.htm System.Reflection.Metadata_MethodSpecification.htm MemoryMappedFile.Tests.dll.coverage.xml System.Reflection.Metadata_MethodSpecTableReader.htm MemoryMappedViewAccessor.Tests.dll.coverage.xml System.Reflection.Metadata_MethodTableReader.htm MemoryMappedViewStream.Tests.dll.coverage.xml System.Reflection.Metadata_ModuleDefinitionHandle.htm Microsoft.Win32.Primitives_Interop.htmSystem.Reflection.Metadata_ModuleDefinition.htm Microsoft.Win32.Primitives.Tests.dll.coverage.xml System.Reflection.Metadata_ModuleReferenceHandle.htm Microsoft.Win32.Primitives_Win32Exception.htm System.Reflection.Metadata_ModuleReference.htm Microsoft.Win32.Registry_Interop.htm System.Reflection.Metadata_ModuleRefTableReader.htm Microsoft.Win32.Registry_Registry.htm System.Reflection.Metadata_ModuleTableReader.htm Microsoft.Win32.Registry_RegistryKey.htm System.Reflection.Metadata_NamespaceCache.htm Microsoft.Win32.Registry_SafeRegistryHandle.htm System.Reflection.Metadata_NamespaceData.htm Microsoft.Win32.Registry_SR.htm System.Reflection.Metadata_NamespaceDefinitionHandle.htm Microsoft.Win32.Registry_Strings.htm System.Reflection.Metadata_NamespaceDefinition.htm Microsoft.Win32.Registry.Tests.dll.coverage.xml System.Reflection.Metadata_NativeHeapMemoryBlock.htm Microsoft.Win32.Registry_ThrowHelper.htm System.Reflection.Metadata_NestedClassTableReader.htm report.cssSystem.Reflection.Metadata_ObjectPool_1.htm ... 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] [htmlpublisher-plugin] (JENKINS-25328) HTML Publisher - HTTP 404 - The requested resource is not available
Matthew Mitchell commented on JENKINS-25328 HTML Publisher - HTTP 404 - The requested resource is not available I'm also seeing this on Jenkins 1.598. 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.
