5.0.2 hangs on a maven site-deploy

I try to use a site-deploy for a project with TC5.0.2 but it always seem to hang at the same stage:

here are the last lines of the build log:

[INFO] Generating changed sets xml to: /opt/local/buildAgent/work/434cbd61a4c449ea/target/changelog.xml
[11:31:24]: [INFO] SCM Working Directory: /opt/local/buildAgent/work/434cbd61a4c449ea/src/main/java
[11:31:24]: [INFO] SCM Command Line[0]: svn
[11:31:24]: [INFO] SCM Command Line[1]: log
[11:31:24]: [INFO] SCM Command Line[2]: -v
[11:31:24]: [INFO] SCM Command Line[3]: -r{2010-02-27}:{2010-01-27}
Running...


this runs fine on a command line.

Any idea?

thank you
-nodje

23 comments
Comment actions Permalink

Try using checkout on agent mode.

If you use checkout on server (the default mode), the project directories on agents don't contain any VCS specific information. In your case maven invokes svn which predictably fails, since there are no .svn entries.

0
Comment actions Permalink

well, it's actually checking out on the agent already. So it's something else.

Here's what the build looks like from the comamnd line:

[INFO] Generating "Tag List" report.
[WARNING] Using legacy tag format.  This is not recommended.
[INFO] Generating "changelog" report.
[INFO] Generating "dev-activity" report.

Here's what it looks like from the TeamCity:

[INFO] Generating "Tag List" report.
[12:17:32]: [WARNING] Using legacy tag format.  This is not recommended.
[12:17:33]: [INFO] Generating "changelog" report.
[12:17:33]: [INFO] Generating changed sets xml to: /opt/local/buildAgent/work/4e57aa6598b1596f/target/changelog.xml
[12:17:33]: [INFO] SCM Working Directory: /opt/local/buildAgent/work/4e57aa6598b1596f/src/main/java
[12:17:33]: [INFO] SCM Command Line[0]: svn
[12:17:33]: [INFO] SCM Command Line[1]: log
[12:17:33]: [INFO] SCM Command Line[2]: -v
[12:17:33]: [INFO] SCM Command Line[3]: -r{2010-03-02}:{2010-01-30}

I don't understand why it seem to issue more commands when it runs on Teamcity.
Could it be the logging style?

Help welcome anyway.

cheers
-nodje

0
Comment actions Permalink

Hm. This could be caused by some difference in the environment.

Did you run the command line maven and the agent under the same user on the same machine?

0
Comment actions Permalink

Yep, both agent and my local build were run under root.

This used to work on TC 4.5.5.

rgds

0
Comment actions Permalink

Hi,
I'm having the same exact problem. The VCS credentials are not taken by TeamCity. As a workaround, I'm using -Duser=... -Dpassword=... in the configuration, but it's not the ideal solution.

Thanks

0
Comment actions Permalink

Sorry for the delay, I missed your answer.

Does the workaround suggested by Deimos work for you?

0
Comment actions Permalink

Sorry, I have been off for a while.

-Duser -Dpassword doesn't do the trick for me.

Are those the proper options to pass in VCS credentials to Maven or are the more specific?

0
Comment actions Permalink

In general, you don't have to specify any additional options in the runner settings if they aren't required for the manual run, simply because TeamCity runs mvn the same way any command shell does. I can't reproduce this problem locally, and I still think of some difference in your environment. Could you please run the command 'export' in you command line and in TeamCity (using simple command runner) and compare the output?

0
Comment actions Permalink

Maybe I misunderstood how to run a Command line in TC, here's what I get when I try to configure a build to run 'export':

RunBuildException when running build stage CallRunnerStage: Cannot run process: Cannot run program "export" (in directory "/opt/local/buildAgent/work/4e57aa6598b1596f"): java.io.IOException: error=2, No such file or directory

I actually tried to get the site-deploy configuration with a Command line, but got the same error as above with the 'mvn' program.

thanks for your help.

0
Comment actions Permalink

Sorry for misleading. It should be 'sh -c export'. But in the command line you can just type 'export'.
mvn fails probably because its containing directory isn't listed in the PATH variable.

0
Comment actions Permalink

Another way is running 'env'. It's even better for comparing since it doesn't show lots of "declare -x".

0
Comment actions Permalink

thanks Sergey.

I wasn't more successful with sh -c export, same error message. But env worked.

Nothing is striking to me.

I kept only the variables that have different values:

CLI:

SHELL=/bin/bash
XDG_SESSION_COOKIE=9428931ea63505c3b620670047e16940-1271658309.616133-423192693
PATH=/usr/lib/jvm/java-6-sun/bin:/opt/local/maven/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/root/Documents/project/project
SHLVL=1
_=/usr/bin/env
OLDPWD=/root


TC:

BUILD_VCS_NUMBER_Project_Trunk_localhost=6203
SHLVL=3
XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt
BUILD_VCS_NUMBER=6203
TEMP=/opt/local/buildAgent/temp/buildTmp
XDG_SESSION_COOKIE=9428931ea63505c3b620670047e16940-1271315550.286361-1557897040
PWD=/opt/local/buildAgent/bin
_=./agent.sh
NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat
BUILD_NUMBER=3
LD_LIBRARY_PATH=/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/server:/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.15/jre/../lib/i386::.:.
OLDPWD=/opt/local/buildAgent/bin
SHELL=/bin/bash
TMP=/opt/local/buildAgent/temp/buildTmp
TEAMCITY_BUILDCONF_NAME=export
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TEAMCITY_VERSION=5.0.3 (build 10821)
TEAMCITY_BUILD_PROPERTIES_FILE=/opt/local/buildAgent/temp/agentTmp/teamcity.build4264454455793131936.properties
TEAMCITY_PROJECT_NAME=project

0
Comment actions Permalink

At first glance the diff doesn't seem to contain something really significant...

Just to check if the source location matters could you please try the following.

Turn off the automatic checkout both on server and agent (or create a separate build configuration without it).
Specify the checkout directory path pointing to the directory where you successfully run site-deploy from the command line.
Run a site-deploy build.

Thank you

0
Comment actions Permalink

Sergey,

the source location does indeed matter.
it worked well when using the source location I use for the manual builds.

At least, it gives a way to run this build automatically by checking out on server specified location.

If you have any idea on why the source location matters, I'd be happy to know of course!

cheers

0
Comment actions Permalink

OK. Then the problem seems to relate to a difference in SVN working copy versions.
Could you please check the version of the SVN command line client installed (svn --version).
Then check the working copy format in the VCS root settings correponds to that version. If it's different, adjust it and try rebuilding with automatic checkout on agent.

0
Comment actions Permalink

I'm not sure I understand what you mean.
The SVN client version is 1.6.5. We use 1.6 format.

How can I control which version and which format is used by TC?

0
Comment actions Permalink

You can control it in the VCS root configuration page. What working copy format is configured for this root?

0
Comment actions Permalink

Thanks to your direction I've found the problem Sergey.
I was checking out from localhost (svn://localshot/...) instead of from the server alias (svn://server/...)

It works when checking out from the server alias and not when from localhost. Don't understand why...

Anyway, it's a solved problem. Thanks a lot for spending the time helping me out.

/nodje

0
Comment actions Permalink

I'm glad it's working now.

It's indeed a strange problem. But now it seems to be closer to Maven

Thank you!

0
Comment actions Permalink

Oddly enough, it works if I do a check out on svn://localhost and launch a site-deploy.
Just checked out of curiosity.

Could it be caused by some management of SVN credentials?

cheers

0
Comment actions Permalink

Hello,

  You should either pass correct credentials on the VCS root configuration screen, or ensure your credentials for the repository URL are cached on build agent machine.
  Probably, after you've accessed SVN from command line, the credentials were cached and it worked from TeamCity.

  This may be the reason why svn://server worked, and svn://localhost didn't. You had cached credentials only for the former variant.

  Anyway, glad this works for you finally

  Regards,
  KIR

0

Please sign in to leave a comment.