Another thing that springs to mind, is the fact that the builds stay
broken for a long time. This isn't just recently, the tests were borked
for months. I think if people are going to make changes that may break
the build for a while, there has to be either better communication as to
why the builds are broken and/or backout the changes or develop on a
branch.
Just leaving Jenkins spamming people isn't much good and doesn't promote
much confidence on people coming to look at the project(although I
admit, they shouldn't necessarily be running trunk).
Tom
On 24/01/15 16:57, Tom Barber wrote:
Aye well Jenkins building off an empty repo is certainly helpful, the
amount of projects I've worked on when someone has some random jar
cached up so it works for them but not anyone else.....
On 24/01/15 16:46, BW wrote:
+1
On Saturday, January 24, 2015, Chris Mattmann<[email protected]> wrote:
+1 to having a common build env/area good
suggestion Cam.
-----Original Message-----
From: Cameron Goodale <[email protected] <javascript:;>>
Reply-To: <[email protected] <javascript:;>>
Date: Saturday, January 24, 2015 at 7:43 AM
To: <[email protected] <javascript:;>>
Subject: Re: OODT Tests
Hey Folks,
I realize I am late to the discussion but in the past when one person has
a
working build and another person is having issues the problem/solution
(depending on how you look at it) is in the local maven repo.
On my local machine Mac OS X 10.9.5 I blew out my maven repo and did an
install from a fresh checkout of trunk and I am getting the same error
that
Lewis has. I believe that Jenkins does it's build/test against an empty
local maven repo.
This is kind of like asking if there is petrol in the tank when a car
breaks down, but I figure it couldn't hurt to mention it.
Good Luck,
Cameron
On Fri, Jan 23, 2015 at 9:37 AM, Tom Barber <[email protected]
<javascript:;>>
wrote:
Its a null pointer disguised as a broken url. I'll take a look later.
Tom
On 23 Jan 2015 17:20, "Ramirez, Paul M (398M)" <
[email protected] <javascript:;>>
wrote:
Weird one. Is there something wrong with your network connection? Is
that
URL being blocked? The stack trace says URL does not exist but I'm
able
to
access it here on my phone.
--Paul
Sent from my iPhone
On Jan 23, 2015, at 9:10 AM, Lewis John Mcgibbney <
[email protected] <javascript:;>> wrote:
Hi Tom,
Thanks for heads up.
I am kinda confused as to local failure, I'm reproducing failures on
Jenkins
Regression on
org.apache.oodt.cas.protocol.http.TestHttpProtocol.testLSandCD
Error Message
Failed to cd to {parent = 'null', path =
'repos/asf/oodt/trunk/protocol/http/src/main/java/org/apache/oodt/cas/pro
tocol/http',
isDir = 'true'} : URL does not exist
'
http://svn.apache.org/repos/asf/oodt/trunk/protocol/http/src/main/java/or
g/apache/oodt/cas/protocol/http
'
Stacktrace
org.apache.oodt.cas.protocol.exceptions.ProtocolException: Failed to
cd to {parent = 'null', path =
'repos/asf/oodt/trunk/protocol/http/src/main/java/org/apache/oodt/cas/pro
tocol/http',
isDir = 'true'} : URL does not exist
'
http://svn.apache.org/repos/asf/oodt/trunk/protocol/http/src/main/java/or
g/apache/oodt/cas/protocol/http
'
at org.apache.oodt.cas.protocol.http.HttpProtocol.cd
(HttpProtocol.java:78)
at
org.apache.oodt.cas.protocol.http.TestHttpProtocol.testLSandCD(TestHttpPr
otocol.java:52)
Caused by: java.io.IOException: URL does not exist
'
http://svn.apache.org/repos/asf/oodt/trunk/protocol/http/src/main/java/or
g/apache/oodt/cas/protocol/http
'
at
org.apache.oodt.cas.protocol.http.util.HttpUtils.isDirectory(HttpUtils.ja
va:126)
at org.apache.oodt.cas.protocol.http.HttpProtocol.cd
(HttpProtocol.java:72)
... 23 more
Caused by: java.lang.NullPointerException
at
org.apache.oodt.cas.metadata.util.MimeTypeUtils.autoResolveContentType(Mi
meTypeUtils.java:223)
at
org.apache.oodt.cas.metadata.util.MimeTypeUtils.autoResolveContentType(Mi
meTypeUtils.java:132)
at
org.apache.oodt.cas.protocol.http.util.HttpUtils.isDirectory(HttpUtils.ja
va:122)
... 24 more
On Fri, Jan 23, 2015 at 8:45 AM, Tom Barber
<[email protected] <javascript:;>>
wrote:
The only real problem with the build is that the Jersey Client 1.x
POM
has
been knackered for god knows how long, but as long as I can
remember
working with REST stuff, and the Hadoop Client jar in the Resource
Manager
has it hardcoded as a dependency. So the other night I forced it to
use
a
newer version, so it failed a few times and I stepped through the
required
upgraded jars.
Apart from that and a few minor tweaks I think its alright.
Tom
On 23/01/15 16:41, Lewis John Mcgibbney wrote:
Hi Folks,
Builds have been dodgy for a while now.
Anyone have a clue what happened?
I just looked at out Jenkins build record for trunk and quite
frankly
it
kinda appalling.
I'm building RADiX for a customer right now then I'm going to take
some
time looking at tests again.
Lewis
--
*Tom Barber* | Technical Director
meteorite bi
*T:* +44 20 8133 3730
*W:*www.meteorite.bi | *Skype:* meteorite.consulting
*A:* Surrey Technology Centre, Surrey Research Park, Guildford, GU2
7YG, UK
--
*Lewis*
--
*Tom Barber* | Technical Director
meteorite bi
*T:* +44 20 8133 3730
*W:* www.meteorite.bi | *Skype:* meteorite.consulting
*A:* Surrey Technology Centre, Surrey Research Park, Guildford, GU2
7YG, UK
--
*Tom Barber* | Technical Director
meteorite bi
*T:* +44 20 8133 3730
*W:* www.meteorite.bi | *Skype:* meteorite.consulting
*A:* Surrey Technology Centre, Surrey Research Park, Guildford, GU2 7YG, UK
