<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>On Monday 08 July 2013 08:24 PM,
Tomaž Cerar wrote:</tt><tt><br>
</tt></div>
<blockquote
cite="mid:CAMquZP40qdvnv2eg5SMjS7vC8BeeFF+DWoi4e81g0qWEgQ0m6w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div><tt><br>
</tt>
<div><tt>...</tt><tt><br>
</tt><tt>In any case i think everyone agrees that UI in
general is much better with TC</tt><tt><br>
</tt></div>
</div>
</div>
</div>
</blockquote>
<tt><br>
</tt><tt>I found it to be the other way around. In fact, for me the
UI for Jenkins is almost non-existent whereas for TeamCity I did
find it to be good enough and intuitive for most parts of it.</tt><tt><br>
<br>
-Jaikiran<br>
</tt>
<blockquote
cite="mid:CAMquZP40qdvnv2eg5SMjS7vC8BeeFF+DWoi4e81g0qWEgQ0m6w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div><tt><br>
</tt><tt><br>
</tt><tt>--</tt><tt><br>
</tt></div>
<div><tt>tomaz</tt><tt><br>
</tt></div>
<div>
<div>
<div><tt><br>
</tt><tt><br>
</tt></div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><tt><br>
</tt><tt><br>
</tt>
<div class="gmail_quote"><tt>On Wed, Jul 3, 2013 at 3:33 PM,
Jaikiran Pai </tt><tt><span dir="ltr"><<a
moz-do-not-send="true" href="mailto:jpai@redhat.com"
target="_blank">jpai@redhat.com</a>></span></tt><tt>
wrote:</tt><tt><br>
</tt>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div><tt>I'll let Tomaz answer that question, but I'll add
some points where I think TeamCity helped a lot
recently when compared to Jenkins. </tt><tt><br>
</tt> <tt><br>
</tt> <tt> Just before 8.0.0.Alpha2 of WildFly was
released, we noticed that our testsuite was in a very
bad shape. Too many intermittent failures. Although,
the intermittent failures weren't a new thing, the
frequency and the number had both grown to an extent
where we felt that we had to start looking into each
of those tests and investigate the problems. I hadn't
used TeamCity earlier but while looking into these
tests, I decided to take a look at the instance
maintained by Tomaz. From an user point of view, I
found the following features extremely handy and in
fact these features did help me with better
investigating the failures and also not losing
interest in trying to track down those test failures:</tt><tt><br>
</tt> <tt><br>
</tt> <tt> 1) "Investigations" feature - TeamCity has
this feature called "investigations" which allows you
to mark a (failed) test or an entire build for
investigation. The investigation can be assigned to a
specific user. Investigations can be auto resolved
(the next time the build/test succeeds) or can be
manually resolved after investigating that failure.
This feature allowed me to keep track of a bunch of
failing tests and monitor their resolution over time.
This is one step between finding a failing test and
creating a JIRA, since this intermediate step allowed
me to spend some time on that test to really
understand what needs to be fixed/changed for that
test to pass. Once I knew what was needed, I could
then either fix it or file the JIRA assigned to the
relevant component/person.</tt><tt> This also was one
way of saying that this specific test failure is a
"known issue which is being investigated on by person
X". This way someone else can spend their time on some
other test failure investigation.</tt><tt><br>
</tt> <tt><br>
</tt> <tt>Investigations also allow "notes" to be
attached to them which allowed me to make a note of
what I have investigated so far and what might be the
issue.</tt><tt><br>
</tt> <tt><br>
</tt> <tt>2) Immediate report and logs of failed tests
- Unlike Jenkins where you have to wait for the entire
testsuite to finish (which can take a hour and a half)
to know how many and which tests failed in that run,
TeamCity shows the progress of the build and reports
the number of failed tests at that point in time in
the build. Furthermore, it shows logs and the failure
details of such tests immediately and you don't have
to wait for the run to complete. I found this
extremely useful since I didn't have to wait for the
entire run to complete. In the past, when I've seen
intermittent failing tests on Jenkins, I haven't had
the determination to try out certain things and check
the results since the thought of having to wait for
another hour and a half would just switch off my
interest on that issue.</tt><tt><br>
</tt> <tt><br>
</tt> <tt>3) Inline logs/stacktrace - I'm not sure why
I like this so much but I really do like this feature
of TeamCity. This and #2 in themselves are the reasons
which kept me interested in tracking down a majority
of the failures. This specific feature is really
simple. When a bunch of tests fail in a build, the
build report page shows all those failed test names
and also for each failed tests allows you to hide/show
stacktrace inline under the testcase name (see this
for example </tt><tt><a moz-do-not-send="true"
href="http://teamcity.cafe-babe.org/viewLog.html?buildId=5666&tab=buildResultsDiv&buildTypeId=pr"
target="_blank">http://teamcity.cafe-babe.org/viewLog.html?buildId=5666&tab=buildResultsDiv&buildTypeId=pr</a></tt><tt>
- click on that test link and it will show up the logs
inline and you can then hide the logs if you want to).
This allowed me to view all those failed tests and
their logs on the same page and hide whichever ones I
didn't want to view. Of course, in Jenkins, you can
view these logs on a separate page/tab for each failed
test, but I find the TeamCity way, much more usable
than the Jenkins way.</tt><tt><br>
</tt> <tt><br>
</tt> <tt>-Jaikiran</tt>
<div>
<div class="h5"><tt><br>
</tt> <tt><br>
</tt> <tt>On Tuesday 02 July 2013 11:50 PM, Vojtech
Juranek wrote:</tt><tt><br>
</tt> </div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<pre>Hi,
</pre>
<blockquote type="cite">
<pre>it works very well.
In many cases much better than what we had with jenkins on lightning.
</pre>
</blockquote>
<pre>could you be more specific please? (not going to try to persuade you to stay
with Jenkins, just wondering what you see as Jenkins weak points and where is
TC better)
Thanks
Vojta</pre>
<tt><br>
</tt>
<fieldset></fieldset>
<tt><br>
</tt> </div>
</div>
<pre>_______________________________________________
wildfly-dev mailing list
<a moz-do-not-send="true" href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
</blockquote>
<tt><br>
</tt> </div>
<tt><br>
</tt><tt>_______________________________________________</tt><tt><br>
</tt><tt>
wildfly-dev mailing list</tt><tt><br>
</tt>
<tt><a moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a></tt><tt><br>
</tt>
<tt><a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></tt><tt><br>
</tt>
<tt><br>
</tt></blockquote>
</div>
<tt><br>
</tt></div>
</blockquote>
<tt><br>
</tt>
</body>
</html>