https://svn.dev.java.net/svn/hudson/branches/rc
........
r23698 | kohsuke | 2009-11-12 19:24:53 -0800 (Thu, 12 Nov 2009) | 1 line
testing if the root cause is a test failure and it's masked by the failure in tearDown
........
r23699 | mindless | 2009-11-12 21:47:16 -0800 (Thu, 12 Nov 2009) | 2 lines
[FIXED HUDSON-4831] prevent duplicate cause entries for a build
........
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23705 71c3de6d-444a-0410-be80-ed276b4c234a
https://svn.dev.java.net/svn/hudson/branches/rc
........
r23689 | kohsuke | 2009-11-12 15:35:27 -0800 (Thu, 12 Nov 2009) | 1 line
improved diagnosability
........
r23690 | kohsuke | 2009-11-12 18:03:42 -0800 (Thu, 12 Nov 2009) | 1 line
adding a probe to diagnose a sporadic test failure
........
r23691 | kohsuke | 2009-11-12 18:14:21 -0800 (Thu, 12 Nov 2009) | 1 line
I think this is causing a test failure in ExtendedReadPermissionTest, as the existing alice/bob/charlie users prevent the data on the disk from loading.
........
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23692 71c3de6d-444a-0410-be80-ed276b4c234a
so these behave the same as other unknown fields (builders, publishers, etc).
Also changed context.convertAnother() calls to simpler reader.getValue()/writer.setValue()
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23637 71c3de6d-444a-0410-be80-ed276b4c234a
"Enable project-based security" always comes up unchecked on configure pages and
project permissions are lost if not rechecked before clicking Save.
Now initialize checkbox with ${instance!=null} instead.
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23630 71c3de6d-444a-0410-be80-ed276b4c234a
Nov 9, 2009 1:46:11 PM hudson.remoting.Channel$ReaderThread run
SEVERE: I/O error in channel This side of the channel
java.io.IOException: Write end dead
at java.io.PipedInputStream.read(PipedInputStream.java:294)
at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2249)
at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2542)
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2552)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at hudson.remoting.Channel$ReaderThread.run(Channel.java:849)
Nov 9, 2009 1:46:11 PM hudson.remoting.Request$2 run
SEVERE: Failed to send back a reply
java.io.IOException: Read end dead
at java.io.PipedInputStream.checkStateForReceive(PipedInputStream.java:246)
at java.io.PipedInputStream.receive(PipedInputStream.java:210)
at java.io.PipedOutputStream.write(PipedOutputStream.java:132)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1838)
at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1747)
at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1249)
at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1203)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1387)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1538)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:329)
at hudson.remoting.Channel.send(Channel.java:413)
at hudson.remoting.Request$2.run(Request.java:282)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
The thread dump indicates that the test thread is stuck at british.join(), because British channel reader thread is still alive. I remember PipedInput|OutputStream being not truly multi-thread aware, so changing it to our own version to see if that fixes the problem without my digging further.
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23625 71c3de6d-444a-0410-be80-ed276b4c234a
caused Content-Length header to no longer be written. wget/curl seem ok with
this, but browsers display nothing for "view as plain text".
Stapler's DefaultScriptInvoker wraps the OutputStream in a filter to prevent
jelly from flushing the output; copied this into Run.doConsoleText and now
the Content-Length header gets written again, for both compressed/plain output.
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23605 71c3de6d-444a-0410-be80-ed276b4c234a
mindless