|
|
|
Hi Rohan,
Can you please attach (or send to support @ zutubi) the log files from the windows agents that are failing and also the windows vista business SP1 machine that is not failing? Regards, -Daniel Attached the log from the XP agent where git fails.
The first error in the log is from a build where a bootstrap is done for the first time. (project is set to "clean update" mode) The second error is from a subsequent bootstrap. The log from the Vista agent which is working correctly has no entries for the same time period. As the backtrace mentions GitClient.java:226, it looks like the problem is in invoking the `log' command.
If I manually log into the XP machine and run the `git log' command I believe Pulse will run, I get this: C:\Documents and Settings\pulseagent\git_test\somerepo>git.cmd log --name-status - c --pretty=format:#%n%H%n%cn%n%cd%n%s%n%b# --reverse -n 1 fatal: ambiguous argument 'and': unknown revision or path not in the working tre e. Use '--' to separate paths from revisions The problem is that %cd% in the pretty-format string expands to my current directory, and that contains a space. My theory is that it fails on XP and not on Vista because on Vista, the pulse agent is under c:\users\pulseagent (no space), while on XP it is under c:\documents and settings\pulseagent (spaces). If I run the same command on the Vista machine, it doesn't fail, however the current path is put into the log messages. e.g., the entries output are: # caab736c126ac6f0e9e908440bbdbf0817dcdd5e Bob Jones C:\Users\pulseagent\git_test\somereponFixed some bug. # Hi Rohan,
Thanks for the extra details. I think, however, the problem you are seeing is because you are typing the command in at the prompt where environment variables (such as %cd%) will be replaced, but this should not be the case when Pulse calls git itself. Are you able to repeat the test but with the % characters escaped with ^? That is: git.cmd log --name-status -c --pretty=format:#^%n^%H^%n^%cn^%n^%cd^%n^%s^%n^%b# --reverse -n 1 I can't test this right now, but I'm pretty certain you're correct and it will work if the characters are escaped. However I don't think it's just a coincidence that my test fails on the same platform in the same git command as Pulse.
My thoughts are that a variable substitution step is taking place somewhere where I didn't expect it. Possibly within git.cmd, which means the bug wouldn't be in Pulse at all. Will test more tomorrow... Hi Rohan,
You are right that it seems more than coincidence - particularly as you are using the same version of git. It may well be that substitution is happening in git.cmd. This may also point to a separate issue with git.cmd -- if it doesn't like the input and is failing, it seems to still exit with code 0 (else Pulse would detect the error on exit and report it differently). Batch files are notorious for not exiting with correct codes, as it can be tricky to get it right. Testing indicates that git.cmd behaves correctly in these two respects: it doesn't introduce an additional substitution step, and it correctly preserves the exit code.
Therefore it doesn't look like the problem is with git.cmd. The manner in which `git.cmd log' failed in my earlier comments might just be a coincidence after all. Is there some way to make logging more verbose on the agents so I can tell for sure what command(s) it is running? Hi Rohan,
The git commands run should appear in the recipe log prefixed by >>, just like the checkout command you pasted in the original description for this issue. I would expect the log command to come after it and take the form you have been testing at the command line. If that command works, then it may be a problem with how we parse the output. If a total parse failure is detected Pulse will show the raw output from the git command, but unfortunately it seems it is just missing the important parts without failing (and there is no way to force it to show raw output at the moment). However, if you can send us the output produced by running the log command at the command line we can test with it to try and reproduce the problem. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Both machines have java 1.6.0_13.