Delayed commit not working in eap 1529

I'm preparing a demo of TeamCity using build 1529 and I just noticed
that the 'delayed commit' feature has stopped working. Here's a summary:

  • open a unit test file for edit in IDEA and add a line to make the

test fail.

  • verify the test fails by running ant from a command line

  • in IDEA, select 'Remote Run' and check the boxes 'Commit if

successful' and 'with confirmation'.

  • build runs, says all is good and asks me to commit change. I say

no.

If I check the source in my buildagent/work directory, it is the
unmodified version of that file instead of the one I edited. I can
then go the other way.

  • Submit file to perforce.

  • Run a build which now fails.

  • Fix test in IDEA

  • Verify it's good via command line run of Ant.

  • Try delayed commit, which now always fails.



So, how exactly is TeamCity supposed to know to grab the files that
IDEA is using? Because it looks to me like it's always grabbing the
files from perforce.

I'm using TC 1529 and IDEA 6.0Beta, build 5581. I installed the
buildServerPlugin in

%HOMEPATH%\.IntelliJIdea60\config\plugins

as the documentation instructs. I reinstalled it from TC just to make
sure I had the correct one.

--
-- Steve

34 comments
Comment actions Permalink

All changes made by delayed commit will be rolled back from an agent (to
improve next build getting sources action - it will not reset all sources).
Maybe the problem is your build script does not return error exit code if
some tests fail. Please check it

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Steve Allan" <takezowest@yahoo.com> wrote in message
news:upsetsl2v.fsf@attachmate.com...

I'm preparing a demo of TeamCity using build 1529 and I just noticed
that the 'delayed commit' feature has stopped working. Here's a summary:

>

  • open a unit test file for edit in IDEA and add a line to make the

test fail.

>

  • verify the test fails by running ant from a command line

>

  • in IDEA, select 'Remote Run' and check the boxes 'Commit if

successful' and 'with confirmation'.

>

  • build runs, says all is good and asks me to commit change. I say

no.

>

If I check the source in my buildagent/work directory, it is the
unmodified version of that file instead of the one I edited. I can
then go the other way.

>

  • Submit file to perforce.

>

  • Run a build which now fails.

>

  • Fix test in IDEA

>

  • Verify it's good via command line run of Ant.

>

  • Try delayed commit, which now always fails.

>
>

So, how exactly is TeamCity supposed to know to grab the files that
IDEA is using? Because it looks to me like it's always grabbing the
files from perforce.

>

I'm using TC 1529 and IDEA 6.0Beta, build 5581. I installed the
buildServerPlugin in

>

%HOMEPATH%\.IntelliJIdea60\config\plugins

>

as the documentation instructs. I reinstalled it from TC just to make
sure I had the correct one.

>

--
-- Steve



0
Comment actions Permalink

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>All changes made by delayed commit will be rolled back from an agent (to
>improve next build getting sources action - it will not reset all
>sources).

Is that only when a build fails, or even if it succeeds? It must be
both because you have no way of being sure the developer is going to
commit his change to the vcs immediately after a successful build.

>Maybe the problem is your build script does not return error exit code if
>some tests fail. Please check it

My Ant script reports 'BUILD FAILED', and %errorlevel% is 1. I
thought this was working in the beta. I installed 1529 to get the new
perforce client behavior and just noticed the delayed commit problem.
I'll try going back to the beta to see if the delayed commit works
there. I'd be surprised if it doesn't or you would have more reports
of it not working. Have you verified that it works for you in build
1529?

Thanks. I'm off to present a demo of TeamCity for one of our Java
groups. I'll have to tap-dance my way around the delayed commit
stuff for now.

--
-- Steve


>
>--
>Olesya Smirnova
>JetBrains, Inc
>http://www.jetbrains.com
>"Develop with pleasure!"
>
>
>"Steve Allan" <takezowest@yahoo.com> wrote in message
>news:upsetsl2v.fsf@attachmate.com...
>> I'm preparing a demo of TeamCity using build 1529 and I just noticed
>> that the 'delayed commit' feature has stopped working. Here's a summary:
>>
>> * open a unit test file for edit in IDEA and add a line to make the
>> test fail.
>>
>> * verify the test fails by running ant from a command line
>>
>> * in IDEA, select 'Remote Run' and check the boxes 'Commit if
>> successful' and 'with confirmation'.
>>
>> * build runs, says all is good and asks me to commit change. I say
>> no.
>>
>> If I check the source in my buildagent/work directory, it is the
>> unmodified version of that file instead of the one I edited. I can
>> then go the other way.
>>
>> * Submit file to perforce.
>>
>> * Run a build which now fails.
>>
>> * Fix test in IDEA
>>
>> * Verify it's good via command line run of Ant.
>>
>> * Try delayed commit, which now always fails.
>>
>>
>> So, how exactly is TeamCity supposed to know to grab the files that
>> IDEA is using? Because it looks to me like it's always grabbing the
>> files from perforce.
>>
>> I'm using TC 1529 and IDEA 6.0Beta, build 5581. I installed the
>> buildServerPlugin in
>>
>> %HOMEPATH%\.IntelliJIdea60\config\plugins
>>
>> as the documentation instructs. I reinstalled it from TC just to make
>> sure I had the correct one.
>>
>> --
>> -- Steve
>
>

--
-- Steve

0
Comment actions Permalink

Is that only when a build fails, or even if it succeeds? It must be
both because you have no way of being sure the developer is going to
commit his change to the vcs immediately after a successful build.


Both, of course.

Have you verified that it works for you in build

1529?


Yes, it works for me.
Could you attach this personal build log?
Thanks for your collaboration!
--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Steve Allan" <takezowest@yahoo.com> wrote in message
news:uejv8spvr.fsf@attachmate.com...

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>
>>All changes made by delayed commit will be rolled back from an agent (to
>>improve next build getting sources action - it will not reset all
>>sources).
>

Is that only when a build fails, or even if it succeeds? It must be
both because you have no way of being sure the developer is going to
commit his change to the vcs immediately after a successful build.

>
>>Maybe the problem is your build script does not return error exit code if
>>some tests fail. Please check it
>

My Ant script reports 'BUILD FAILED', and %errorlevel% is 1. I
thought this was working in the beta. I installed 1529 to get the new
perforce client behavior and just noticed the delayed commit problem.
I'll try going back to the beta to see if the delayed commit works
there. I'd be surprised if it doesn't or you would have more reports
of it not working. Have you verified that it works for you in build
1529?

>

Thanks. I'm off to present a demo of TeamCity for one of our Java
groups. I'll have to tap-dance my way around the delayed commit
stuff for now.

>

--
-- Steve

>
>
>>
>>--
>>Olesya Smirnova
>>JetBrains, Inc
>>http://www.jetbrains.com
>>"Develop with pleasure!"
>>
>>
>>"Steve Allan" <takezowest@yahoo.com> wrote in message
>>news:upsetsl2v.fsf@attachmate.com...
>>> I'm preparing a demo of TeamCity using build 1529 and I just noticed
>>> that the 'delayed commit' feature has stopped working. Here's a summary:
>>>
>>> * open a unit test file for edit in IDEA and add a line to make the
>>> test fail.
>>>
>>> * verify the test fails by running ant from a command line
>>>
>>> * in IDEA, select 'Remote Run' and check the boxes 'Commit if
>>> successful' and 'with confirmation'.
>>>
>>> * build runs, says all is good and asks me to commit change. I say
>>> no.
>>>
>>> If I check the source in my buildagent/work directory, it is the
>>> unmodified version of that file instead of the one I edited. I can
>>> then go the other way.
>>>
>>> * Submit file to perforce.
>>>
>>> * Run a build which now fails.
>>>
>>> * Fix test in IDEA
>>>
>>> * Verify it's good via command line run of Ant.
>>>
>>> * Try delayed commit, which now always fails.
>>>
>>>
>>> So, how exactly is TeamCity supposed to know to grab the files that
>>> IDEA is using? Because it looks to me like it's always grabbing the
>>> files from perforce.
>>>
>>> I'm using TC 1529 and IDEA 6.0Beta, build 5581. I installed the
>>> buildServerPlugin in
>>>
>>> %HOMEPATH%\.IntelliJIdea60\config\plugins
>>>
>>> as the documentation instructs. I reinstalled it from TC just to make
>>> sure I had the correct one.
>>>
>>> --
>>> -- Steve
>>
>>
>

--
-- Steve



0
Comment actions Permalink

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>Have you verified that it works for you in build
>> 1529?
>
>Yes, it works for me.
>Could you attach this personal build log?
>Thanks for your collaboration!

I've tested build 1529 on two different servers and get the same
behavior. I'm going to roll one of the servers back to the beta and
test that.

Attached is a tar ball of the test project. It's very small and
simple. Maybe you'll something I'm missing.

Thanks!

--
-- Steve



Attachment(s):
tsdemo.tar.gz
0
Comment actions Permalink

Steve Allan <takezowest@yahoo.com> writes:

>I've tested build 1529 on two different servers and get the same
>behavior. I'm going to roll one of the servers back to the beta and
>test that.

Well, I've spent most of the day on this and have nothing but
frustration to show for it. I put the original beta on and with that
build I was getting correct success/failure notices in IDEA, but the
changes were not being submitted to perforce even though I checked the
box and approved the commit. If I just submit the change from IDEA
without the remote run, it goes through fine.

Then I decided to remove TeamCity completely from my laptop. I
deleted the webapp folder and found every .BuildServer folder on the
machine and deleted that (I actually found 3 .BuildServer folders on
the machine). Then I installed 1529 and recreated my test build.
Works fine in the webapp. Next I installed the buildserver plugin and
fired up IDEA to try the delayed commit again. As soon as it begins
the remote build, IDEA crashes. Sigh. I'm afraid I've had enough for
today.

Any idea when the next eap will be released? Maybe I'll have better
luck with that.

--
-- Steve

0
Comment actions Permalink

I'm testing delayed commit using TeamCity-1529 and IDEA plugin with IDEA
beta version.

The only problem was that I started IDEA when another IDEA instance was
started and xmlrpc server in the second one (testing instance) was not
started. When I restarted IDEA with another rpc.port property it reported
about all delayed commit sessions run in the previous IDEA instance, but new
instance reports about failed and successful builds correctly (I'm using
your test project). BTW, what IDEA version are you using? What version
control? I tested it with cvs.

I'm not sure new eap version will fix the problem because there where no
significant changes in the delayed commit, and version 1529 works for me.

If you have some logs from the problem builds, please send it to me. I mean
server logs for personal build being reported as successful.
Thanks!

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Steve Allan" <takezowest@yahoo.com> wrote in message
news:upsesqtx8.fsf@attachmate.com...

Steve Allan <takezowest@yahoo.com> writes:

>
>>I've tested build 1529 on two different servers and get the same
>>behavior. I'm going to roll one of the servers back to the beta and
>>test that.
>

Well, I've spent most of the day on this and have nothing but
frustration to show for it. I put the original beta on and with that
build I was getting correct success/failure notices in IDEA, but the
changes were not being submitted to perforce even though I checked the
box and approved the commit. If I just submit the change from IDEA
without the remote run, it goes through fine.

>

Then I decided to remove TeamCity completely from my laptop. I
deleted the webapp folder and found every .BuildServer folder on the
machine and deleted that (I actually found 3 .BuildServer folders on
the machine). Then I installed 1529 and recreated my test build.
Works fine in the webapp. Next I installed the buildserver plugin and
fired up IDEA to try the delayed commit again. As soon as it begins
the remote build, IDEA crashes. Sigh. I'm afraid I've had enough for
today.

>

Any idea when the next eap will be released? Maybe I'll have better
luck with that.

>

--
-- Steve



0
Comment actions Permalink

As mentioned in http://www.intellij.net/forums/message.jspa?messageID=5145383#5145383, I'm seeing similar problems. I was never able to get delayed commit to actually commit. I'll try it some more today to see if I can get anything going. Or at least better details on exactly how it is failing.

--Tim

0
Comment actions Permalink

It would be great. Thanks!

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Tim McNerney" <intellij@oneofus.org> wrote in message
news:18018846.1156350394283.JavaMail.itn@is.intellij.net...

As mentioned in
http://www.intellij.net/forums/message.jspa?messageID=5145383#5145383, I'm
seeing similar problems. I was never able to get delayed commit to
actually commit. I'll try it some more today to see if I can get anything
going. Or at least better details on exactly how it is failing.

>

--Tim



0
Comment actions Permalink

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>I'm testing delayed commit using TeamCity-1529 and IDEA plugin with IDEA
>beta version.
>
>The only problem was that I started IDEA when another IDEA instance was
>started and xmlrpc server in the second one (testing instance) was not
>started. When I restarted IDEA with another rpc.port property it reported
>about all delayed commit sessions run in the previous IDEA instance, but new
>instance reports about failed and successful builds correctly (I'm using
>your test project). BTW, what IDEA version are you using?

IDEA 6.0 Beta, build 5581.

>What version control? I tested it with cvs.

Perforce 2005.2.

>
>I'm not sure new eap version will fix the problem because there where no
>significant changes in the delayed commit, and version 1529 works for me.
>
>If you have some logs from the problem builds, please send it to me. I mean
>server logs for personal build being reported as successful.

Where would I find the log you're asking about? I found

~/.BuildServer/buildserver.log

but it's logging database activity and doesn't appear useful.

Thanks.

--
-- Steve

0
Comment actions Permalink

Where would I find the log you're asking about?


Open build page on web, navigate to Build Log, select 'All Messages'.
Just copy the page content

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Steve Allan" <takezowest@yahoo.com> wrote in message
news:ulkpfs7ie.fsf@attachmate.com...

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>
>>I'm testing delayed commit using TeamCity-1529 and IDEA plugin with IDEA
>>beta version.
>>
>>The only problem was that I started IDEA when another IDEA instance was
>>started and xmlrpc server in the second one (testing instance) was not
>>started. When I restarted IDEA with another rpc.port property it reported
>>about all delayed commit sessions run in the previous IDEA instance, but
>>new
>>instance reports about failed and successful builds correctly (I'm using
>>your test project). BTW, what IDEA version are you using?
>

IDEA 6.0 Beta, build 5581.

>
>>What version control? I tested it with cvs.
>

Perforce 2005.2.

>
>>
>>I'm not sure new eap version will fix the problem because there where no
>>significant changes in the delayed commit, and version 1529 works for me.
>>
>>If you have some logs from the problem builds, please send it to me. I
>>mean
>>server logs for personal build being reported as successful.
>

Where would I find the log you're asking about? I found

>

~/.BuildServer/buildserver.log

>

but it's logging database activity and doesn't appear useful.

>

Thanks.

>

--
-- Steve



0
Comment actions Permalink

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:
>> Where would I find the log you're asking about?
>
>Open build page on web, navigate to Build Log, select 'All Messages'.
>Just copy the page content

Oh, you want the build log. I guess I was overthinking that one.

Ok, Here's where I'm at now. I consistently get slightly different,
but bad behavior using builds 1492 and 1529. In both cases I'm using
IDEA 6.0 beta build 5581 on WinXP SP2. I break the unit test outside
of IDEA, then I go into IDEA, fix the test and run the 'delayed
commit' process.

1492 behavior
=============
Correctly reports success, but the fails to commit the change to
perforce. In IDEA, file is moved from the 'delayed commit' changelist
back to the default changelist.

Contents of Build log:

Checking for changes (<1s)
Building in c:\builda~1\work\TSDemoGetting project sources (<1s)
property (<1s)
property (<1s)
property (<1s)
Created dir: C:\builda~1\work\TSDemo\classes
Compiling 1 source file to C:\builda~1\work\TSDemo\classestest (6s)
Compiling 1 source file to C:\builda~1\work\TSDemo\classes
testIsGood (<1s)
all (<1s)

1529 behavior
=============
Reports a failed build, even though if I run the build inside or
outside of IDEA, it succeeds. It behaves as if the change in my
delayed commit changelist isn't getting applied to the remote build
source. Note that in build 1592 I'm providing the name of my client
spec, rather than using the client mapping interface in TC.

Contents of Build log:

test (7s)
testIsGood (<1s)
junit.framework.AssertionFailedError: Oops, not good!
junit.framework.AssertionFailedError: Oops, not good!
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at TSDemoTest.testIsGood(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:1072)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:682)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1434)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:632)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)


Process output:
C:\sw\jdk1.5.0_07\bin\java.exe "-Dbuild.working.dir=c:\builda1\work\TeamCity Demo" -DDotNetFramework1.1_Path=C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 -Dbuild.number=5 "-Demma.instrumentation.parameters=-ix -Test" -DDotNetFramework1.1= -Duser.language=en -Duser.country=US -Didea.build.server.buildType.id=bt1_10 -Dos.version=5.1 -Duser.timezone=America/Los_Angeles -Dfile.encoding=Cp1252 -Dagent.work.dir=c:\builda1\work -Dfile.separator=\ -DDotNetFramework2.0_Path=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 -Dos.arch=x86 -DDotNetFramework2.0= -Duser.name=SYSTEM "-Dos.name=Windows XP" -Dbuild.is.personal=true -Dant.task.extensions=jetbrains.buildServer.agent.ant.EchoAntExtension,jetbrains.buildServer.agent.ant.CompilerAntExtension,jetbrains.buildServer.coverage.AntCoverageAdapter, -Didea.build.agent.port=9090 -Duser.variant= -Dagent.classpath=C:/BuildAgent/lib/buildServerServerLogging.jar;C:/BuildAgent/lib/buildServerXmlRpcWrapper.jar;C:/BuildAgent/plugins/ant/lib/ant-launcher.jar;C:/BuildAgent/lib/junit-3.8.1.jar;C:/BuildAgent/lib/buildServerCommonRuntime.jar;C:/BuildAgent/lib/commons-codec-1.3.jar;C:/BuildAgent/lib/xpp3_min-1.1.3.4.M.jar;C:/BuildAgent/lib/utils.jar;C:/BuildAgent/lib/buildServerMessages.jar;C:/BuildAgent/plugins/coveragePlugin/lib/emma.jar;C:/BuildAgent/plugins/coveragePlugin/lib/buildServerCoverageAgent.jar;C:/BuildAgent/lib/xmlrpc-2.0.1.jar;C:/BuildAgent/plugins/antPlugin/lib/buildServerAntServerLogging.jar;C:/BuildAgent/lib/nanocontainer-1.0-RC-1.jar;C:/BuildAgent/lib/xstream-1.1.2.jar -Dsuccessful.build.number=0 "-Duser.home=C:\Documents and Settings\Default User" -Didea.build.server.build.id=12 -Dant.home=c:\builda1\bin\..\plugins\ant -Dpath.separator=; -classpath C:\BuildAgent\plugins\ant\lib\ant-launcher.jar org.apache.tools.ant.launch.Launcher -lib C:/BuildAgent/lib/junit-3.8.1.jar;C:/BuildAgent/lib/buildServerRuntimeUtil.jar;C:/BuildAgent/plugins/antPlugin/lib/buildServerAntRunntime.jar -listener jetbrains.buildServer.agent.ant.AgentBuildListener -buildfile "c:\builda1\work\TeamCity Demo\tsdemo\build.xml"

Buildfile: c:\builda~1\work\TeamCity Demo\tsdemo\build.xml

init:
Created dir: C:\builda~1\work\TeamCity Demo\tsdemo\classes

compile:
Compiling 1 source file to C:\builda~1\work\TeamCity Demo\tsdemo\classes

test:
Compiling 1 source file to C:\builda~1\work\TeamCity Demo\tsdemo\classes
Changes to environment variables are ignored if running in the same VM.

BUILD FAILED
C:\builda~1\work\TeamCity Demo\tsdemo\build.xml:15: Test TSDemoTest failed

Total time: 13 seconds



If I run the unit test in IDEA (right click, run TSDemoTest) it
succeeds. If I call my Ant script from the command line in the same
workspace, I get

Buildfile: build.xml

init:

compile:

test:
Compiling 1 source file to c:\projects\tsdemo\classes

all:

BUILD SUCCESSFUL
Total time: 1 second

Now I can submit my fix anyway by bypassing the remote run. Then I
can check it out again in IDEA and add a comment, something that won't
break the build. Now the remote build succeeds, but as with 1492, the
change doesn't get submitted to perforce.

That's pretty much it. Is there anything else I can provide you?

Thanks.

--
-- Steve

0
Comment actions Permalink

BTW, did you update IDEA plugin before using another server version? It
might be result of working with incompatible plugin version.


>Now the remote build succeeds, but as with 1492, the
>change doesn't get submitted to perforce.

Plugin reopens files after delayed commit (it is fixed in the next eap,
plugin will not reopen unchanged files), so, if you didn't check file
history and guess that file wasn't commited because you see it in the
changes, check revision history for the file.
--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Steve Allan" <takezowest@yahoo.com> wrote in message
news:uejv7s3q1.fsf@attachmate.com...
"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:
>> Where would I find the log you're asking about?
>
>Open build page on web, navigate to Build Log, select 'All Messages'.
>Just copy the page content

Oh, you want the build log. I guess I was overthinking that one.

Ok, Here's where I'm at now. I consistently get slightly different,
but bad behavior using builds 1492 and 1529. In both cases I'm using
IDEA 6.0 beta build 5581 on WinXP SP2. I break the unit test outside
of IDEA, then I go into IDEA, fix the test and run the 'delayed
commit' process.

1492 behavior
=============
Correctly reports success, but the fails to commit the change to
perforce. In IDEA, file is moved from the 'delayed commit' changelist
back to the default changelist.

Contents of Build log:

Checking for changes (<1s)
Building in c:\builda~1\work\TSDemoGetting project sources (<1s)
property (<1s)
property (<1s)
property (<1s)
Created dir: C:\builda~1\work\TSDemo\classes
Compiling 1 source file to C:\builda~1\work\TSDemo\classestest
(6s)
Compiling 1 source file to C:\builda~1\work\TSDemo\classes
testIsGood (<1s)
all (<1s)

1529 behavior
=============
Reports a failed build, even though if I run the build inside or
outside of IDEA, it succeeds. It behaves as if the change in my
delayed commit changelist isn't getting applied to the remote build
source. Note that in build 1592 I'm providing the name of my client
spec, rather than using the client mapping interface in TC.

Contents of Build log:

test (7s)
testIsGood (<1s)
junit.framework.AssertionFailedError: Oops, not good!
junit.framework.AssertionFailedError: Oops, not good!
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at TSDemoTest.testIsGood(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:1072)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:682)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1434)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:632)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)


Process output:
C:\sw\jdk1.5.0_07\bin\java.exe
"-Dbuild.working.dir=c:\builda~1\work\TeamCity
Demo" -DDotNetFramework1.1_Path=C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
-Dbuild.number=5
"-Demma.instrumentation.parameters=-ix -Test" -DDotNetFramework1.1= -Duser.language=en
-Duser.country=US -Didea.build.server.buildType.id=bt1_10 -Dos.version=5.1
-Duser.timezone=America/Los_Angeles -Dfile.encoding=Cp1252 -Dagent.work.dir=c:\builda~1\work
-Dfile.separator=\ -DDotNetFramework2.0_Path=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
-Dos.arch=x86 -DDotNetFramework2.0= -Duser.name=SYSTEM "-Dos.name=Windows
XP" -Dbuild.is.personal=true -Dant.task.extensions=jetbrains.buildServer.agent.ant.EchoAntExtension,jetbrains.buildServer.agent.ant.CompilerAntExtension,jetbrains.buildServer.coverage.AntCoverageAdapter,
-Didea.build.agent.port=9090 -Duser.variant= -Dagent.classpath=C:/BuildAgent/lib/buildServerServerLogging.jar;C:/BuildAgent/lib/buildServerXmlRpcWrapper.jar;C:/BuildAgent/plugins/ant/lib/ant-launcher.jar;C:/BuildAgent/lib/junit-3.8.1.jar;C:/BuildAgent/lib/buildServerCommonRuntime.jar;C:/BuildAgent/lib/commons-codec-1.3.jar;C:/BuildAgent/lib/xpp3_min-1.1.3.4.M.jar;C:/BuildAgent/lib/utils.jar;C:/BuildAgent/lib/buildServerMessages.jar;C:/BuildAgent/plugins/coveragePlugin/lib/emma.jar;C:/BuildAgent/plugins/coveragePlugin/lib/buildServerCoverageAgent.jar;C:/BuildAgent/lib/xmlrpc-2.0.1.jar;C:/BuildAgent/plugins/antPlugin/lib/buildServerAntServerLogging.jar;C:/BuildAgent/lib/nanocontainer-1.0-RC-1.jar;C:/BuildAgent/lib/xstream-1.1.2.jar
-Dsuccessful.build.number=0 "-Duser.home=C:\Documents and Settings\Default
User" -Didea.build.server.build.id=12 -Dant.home=c:\builda~1\bin\..\plugins\ant
-Dpath.separator=; -classpath
C:\BuildAgent\plugins\ant\lib\ant-launcher.jar
org.apache.tools.ant.launch.Launcher -lib
C:/BuildAgent/lib/junit-3.8.1.jar;C:/BuildAgent/lib/buildServerRuntimeUtil.jar;C:/BuildAgent/plugins/antPlugin/lib/buildServerAntRunntime.jar
-listener jetbrains.buildServer.agent.ant.AgentBuildListener -buildfile
"c:\builda~1\work\TeamCity Demo\tsdemo\build.xml"

Buildfile: c:\builda~1\work\TeamCity Demo\tsdemo\build.xml

init:
Created dir: C:\builda~1\work\TeamCity Demo\tsdemo\classes

compile:
Compiling 1 source file to C:\builda~1\work\TeamCity
Demo\tsdemo\classes

test:
Compiling 1 source file to C:\builda~1\work\TeamCity
Demo\tsdemo\classes
Changes to environment variables are ignored if running in the
same VM.

BUILD FAILED
C:\builda~1\work\TeamCity Demo\tsdemo\build.xml:15: Test TSDemoTest failed

Total time: 13 seconds



If I run the unit test in IDEA (right click, run TSDemoTest) it
succeeds. If I call my Ant script from the command line in the same
workspace, I get

Buildfile: build.xml

init:

compile:

test:
Compiling 1 source file to c:\projects\tsdemo\classes

all:

BUILD SUCCESSFUL
Total time: 1 second

Now I can submit my fix anyway by bypassing the remote run. Then I
can check it out again in IDEA and add a comment, something that won't
break the build. Now the remote build succeeds, but as with 1492, the
change doesn't get submitted to perforce.

That's pretty much it. Is there anything else I can provide you?

Thanks.

--
-- Steve


0
Comment actions Permalink

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>BTW, did you update IDEA plugin before using another server version? It
>might be result of working with incompatible plugin version.

Yes I updated the plugin. As I think more about the 1529 behavior,
I'm suspecting the remote build failure is related to the new perforce
interface. I'm assuming you're using perforce to determine the
pending changes on the client and 'integrating' those changes into the
source for the remote build. Maybe that part isn't working properly
when a client name is given, but not a client view. That feature is
new in build 1529 and that would explain why it works in 1492 but not
in 1529. The behavior very much suggests that it's compiling the
source straight from perforce without my changes merged in.

>Plugin reopens files after delayed commit (it is fixed in the next eap,
>plugin will not reopen unchanged files), so, if you didn't check file
>history and guess that file wasn't commited because you see it in the
>changes, check revision history for the file.

Yes, that's exactly what was happening. So that mystery is solved!
I'm glad to hear that's being changed in the next eap.

Thanks for all your help.

--
-- Steve

0
Comment actions Permalink

I was definitely working with the correct version of the plugin.

I was working with CVS.

I'm not sure if I was working with the offical Beta or 5350. I have them both installed.

One thing of note, I have several builds which the checkin triggers, though I only indicate the compile build in the dialog. It passed the compile build, but failed on some of the others. Don't know if it is trying to overthink the situation and fails because some of the other builds fail.

--Tim

0
Comment actions Permalink

Hello Tim,
the problem is you selected several builds in delayed commit diealo, one of
them failed and files were not checked in? It's correct behaviour, because
file will be checked in if all builds selected to be verified will succeed.
If I didn't understand the problem, please submit bug request. Thanks!

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Tim McNerney" <intellij@oneofus.org> wrote in message
news:12917524.1156370306308.JavaMail.itn@is.intellij.net...
>I was definitely working with the correct version of the plugin.
>

I was working with CVS.

>

I'm not sure if I was working with the offical Beta or 5350. I have them
both installed.

>

One thing of note, I have several builds which the checkin triggers,
though I only indicate the compile build in the dialog. It passed the
compile build, but failed on some of the others. Don't know if it is
trying to overthink the situation and fails because some of the other
builds fail.

>

--Tim



0
Comment actions Permalink

Plugin doesn't use perforce settings on the web, but sources layout on agent
depends on the settings. Please check that the file relative path on agent
is the same as the file path in IDEA project related to the project root
(common parent of all content roots).

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Steve Allan" <takezowest@yahoo.com> wrote in message
news:u7j0zrzw4.fsf@attachmate.com...

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>
>>BTW, did you update IDEA plugin before using another server version? It
>>might be result of working with incompatible plugin version.
>

Yes I updated the plugin. As I think more about the 1529 behavior,
I'm suspecting the remote build failure is related to the new perforce
interface. I'm assuming you're using perforce to determine the
pending changes on the client and 'integrating' those changes into the
source for the remote build. Maybe that part isn't working properly
when a client name is given, but not a client view. That feature is
new in build 1529 and that would explain why it works in 1492 but not
in 1529. The behavior very much suggests that it's compiling the
source straight from perforce without my changes merged in.

>
>>Plugin reopens files after delayed commit (it is fixed in the next eap,
>>plugin will not reopen unchanged files), so, if you didn't check file
>>history and guess that file wasn't commited because you see it in the
>>changes, check revision history for the file.
>

Yes, that's exactly what was happening. So that mystery is solved!
I'm glad to hear that's being changed in the next eap.

>

Thanks for all your help.

>

--
-- Steve



0
Comment actions Permalink

No. I selected one build, it passed. There were other builds which were triggered by the checkin which failed. My changes never got committed. I had to do it by hand.

--Tim

0
Comment actions Permalink

Maybe they were reopened after commit? There is a bug - all files ( not
changed only) are reopened after commit (if you changed file after delayed
commit was invoked it is valid behaviour). You can check it using file
history

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Tim McNerney" <intellij@oneofus.org> wrote in message
news:9009419.1156429475172.JavaMail.itn@is.intellij.net...

No. I selected one build, it passed. There were other builds which were
triggered by the checkin which failed. My changes never got committed. I
had to do it by hand.

>

--Tim



0
Comment actions Permalink

No. I checked externally to see if my changes made it in after the successful build and they were not.

I'll work on trying to get a more detailed rundown of what exactly happened.

--Tim

0
Comment actions Permalink

Ok.
Please submit bug request - it will be more convenient to track the problem
status.
--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Tim McNerney" <intellij@oneofus.org> wrote in message
news:4119723.1156439745206.JavaMail.itn@is.intellij.net...

No. I checked externally to see if my changes made it in after the
successful build and they were not.

>

I'll work on trying to get a more detailed rundown of what exactly
happened.

>

--Tim



0
Comment actions Permalink

http://www.jetbrains.net/jira/browse/TW-727

Looks like the problem may be that though the plugin and webpage both show success for the build, the log and an email claim that the build failed.

--Tim

0
Comment actions Permalink

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>Plugin doesn't use perforce settings on the web, but sources layout on agent
>depends on the settings. Please check that the file relative path on agent
>is the same as the file path in IDEA project related to the project root
>(common parent of all content roots).

The implication of that question worries me, but leaving that aside
for now I'll say that the client spec used on TeamCity was created
using the development client spec as a template, i.e

p4 -t devclient tcclient


I tested this on a real project that takes about 20 minutes to run. I
edited a unit test and added an

assertTrue(false);

and then did a remote build. I watched teamcity get the source and
then at the point where it was actually compiling code I had time to
open the 'modified' file in the work directory on the build agent.
That file did not have my change. As a result, the test build
succeeded when it should have failed. I don't know what else I can do
other then keep saying that it is not working for me. If there's
logging I can turn on, or you'd like to send me some new jar files
with verbose output that might help track this down, I'll be happy to
try that. Otherwise, I'm stuck.

Thanks.

--
-- Steve

0
Comment actions Permalink

The thread is getting a little bit long, please submit bug request.
To the request please attach you client spec (I mean client you're using for
test project).

Turn off commit if successful option and run remote build again. Server
system directory contains 'changes' subdirectory. Patch file will be saved
as #BUILD_ID#.changes file. Please attach it too.

Thanks!

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Steve Allan" <takezowest@yahoo.com> wrote in message
news:uzmdollus.fsf@attachmate.com...

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>
>>Plugin doesn't use perforce settings on the web, but sources layout on
>>agent
>>depends on the settings. Please check that the file relative path on agent
>>is the same as the file path in IDEA project related to the project root
>>(common parent of all content roots).
>

The implication of that question worries me, but leaving that aside
for now I'll say that the client spec used on TeamCity was created
using the development client spec as a template, i.e

>

p4 -t devclient tcclient

>
>

I tested this on a real project that takes about 20 minutes to run. I
edited a unit test and added an

>

assertTrue(false);

>

and then did a remote build. I watched teamcity get the source and
then at the point where it was actually compiling code I had time to
open the 'modified' file in the work directory on the build agent.
That file did not have my change. As a result, the test build
succeeded when it should have failed. I don't know what else I can do
other then keep saying that it is not working for me. If there's
logging I can turn on, or you'd like to send me some new jar files
with verbose output that might help track this down, I'll be happy to
try that. Otherwise, I'm stuck.

>

Thanks.

>

--
-- Steve



0
Comment actions Permalink

Hello, Steve.
Is the problem still reproducable?

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Steve Allan" <takezowest@yahoo.com> wrote in message
news:uzmdollus.fsf@attachmate.com...

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>
>>Plugin doesn't use perforce settings on the web, but sources layout on
>>agent
>>depends on the settings. Please check that the file relative path on agent
>>is the same as the file path in IDEA project related to the project root
>>(common parent of all content roots).
>

The implication of that question worries me, but leaving that aside
for now I'll say that the client spec used on TeamCity was created
using the development client spec as a template, i.e

>

p4 -t devclient tcclient

>
>

I tested this on a real project that takes about 20 minutes to run. I
edited a unit test and added an

>

assertTrue(false);

>

and then did a remote build. I watched teamcity get the source and
then at the point where it was actually compiling code I had time to
open the 'modified' file in the work directory on the build agent.
That file did not have my change. As a result, the test build
succeeded when it should have failed. I don't know what else I can do
other then keep saying that it is not working for me. If there's
logging I can turn on, or you'd like to send me some new jar files
with verbose output that might help track this down, I'll be happy to
try that. Otherwise, I'm stuck.

>

Thanks.

>

--
-- Steve



0
Comment actions Permalink

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>Hello, Steve.
>Is the problem still reproducable?

Yes. I can reproduce it in build 1574 also.

>
>--
>Olesya Smirnova
>JetBrains, Inc
>http://www.jetbrains.com
>"Develop with pleasure!"
>
>
>"Steve Allan" <takezowest@yahoo.com> wrote in message
>news:uzmdollus.fsf@attachmate.com...
>> "Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:
>>
>>>Plugin doesn't use perforce settings on the web, but sources layout on
>>>agent
>>>depends on the settings. Please check that the file relative path on agent
>>>is the same as the file path in IDEA project related to the project root
>>>(common parent of all content roots).
>>
>> The implication of that question worries me, but leaving that aside
>> for now I'll say that the client spec used on TeamCity was created
>> using the development client spec as a template, i.e
>>
>> p4 -t devclient tcclient
>>
>>
>> I tested this on a real project that takes about 20 minutes to run. I
>> edited a unit test and added an
>>
>> assertTrue(false);
>>
>> and then did a remote build. I watched teamcity get the source and
>> then at the point where it was actually compiling code I had time to
>> open the 'modified' file in the work directory on the build agent.
>> That file did not have my change. As a result, the test build
>> succeeded when it should have failed. I don't know what else I can do
>> other then keep saying that it is not working for me. If there's
>> logging I can turn on, or you'd like to send me some new jar files
>> with verbose output that might help track this down, I'll be happy to
>> try that. Otherwise, I'm stuck.
>>
>> Thanks.
>>
>> --
>> -- Steve
>
>

--
-- Steve

0
Comment actions Permalink

What port does the IDEA plugin listen to by default? I turned off my firewall to get delayed checkin working, but I'd now like to simply open that port up and keep the firewall running.

Thanks.

--Tim

0
Comment actions Permalink

Did you submit a request? I cannot find it.
I need file with changes (#BUILD_ID#.changes) to clarify were the problem
is.
--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Steve Allan" <takezowest@yahoo.com> wrote in message
news:u7j0i6kys.fsf@attachmate.com...

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>
>>Hello, Steve.
>>Is the problem still reproducable?
>

Yes. I can reproduce it in build 1574 also.

>
>>
>>--
>>Olesya Smirnova
>>JetBrains, Inc
>>http://www.jetbrains.com
>>"Develop with pleasure!"
>>
>>
>>"Steve Allan" <takezowest@yahoo.com> wrote in message
>>news:uzmdollus.fsf@attachmate.com...
>>> "Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:
>>>
>>>>Plugin doesn't use perforce settings on the web, but sources layout on
>>>>agent
>>>>depends on the settings. Please check that the file relative path on
>>>>agent
>>>>is the same as the file path in IDEA project related to the project root
>>>>(common parent of all content roots).
>>>
>>> The implication of that question worries me, but leaving that aside
>>> for now I'll say that the client spec used on TeamCity was created
>>> using the development client spec as a template, i.e
>>>
>>> p4 -t devclient tcclient
>>>
>>>
>>> I tested this on a real project that takes about 20 minutes to run. I
>>> edited a unit test and added an
>>>
>>> assertTrue(false);
>>>
>>> and then did a remote build. I watched teamcity get the source and
>>> then at the point where it was actually compiling code I had time to
>>> open the 'modified' file in the work directory on the build agent.
>>> That file did not have my change. As a result, the test build
>>> succeeded when it should have failed. I don't know what else I can do
>>> other then keep saying that it is not working for me. If there's
>>> logging I can turn on, or you'd like to send me some new jar files
>>> with verbose output that might help track this down, I'll be happy to
>>> try that. Otherwise, I'm stuck.
>>>
>>> Thanks.
>>>
>>> --
>>> -- Steve
>>
>>
>

--
-- Steve



0
Comment actions Permalink

63342 by default

--
Olesya Smirnova
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


"Tim McNerney" <intellij@oneofus.org> wrote in message
news:6300970.1157498820406.JavaMail.itn@is.intellij.net...

What port does the IDEA plugin listen to by default? I turned off my
firewall to get delayed checkin working, but I'd now like to simply open
that port up and keep the firewall running.

>

Thanks.

>

--Tim



0
Comment actions Permalink

"Olesya Smirnova" <Olesya.Smirnova@jetbrains.com> writes:

>Did you submit a request? I cannot find it.
>I need file with changes (#BUILD_ID#.changes) to clarify were the problem
>is.

Yes:

http://www.jetbrains.net/jira/browse/TW-749

See the attached file delayed-commit.zip for the team-server.log file
and two #BUILD_ID#.changes files.

--
-- Steve

0
Comment actions Permalink

The port # should probably be in the docs somewhere. If it already is, I was unable to find it.

Better still, of course, would be the plugin doing a roundtrip test when initially connecting to the server to confirm that information can flow both ways.

--Tim

0

Please sign in to leave a comment.