Community
Participate
Working Groups
All tests pass locally (on Windows), but I will have a look while they fail on the server (which I assume is a Linux).
Andrew, I ran those tests on a Linux box I have over here and they all passed. Any idea why they fail on the server? Might the tests and the code they run against got out of sync?
Running locally on my linux.x86_64 using an IBM 1.6 vm, I get 2 failures: GitCloneTest#testCloneAndLink: I think this is just a problem with the test, the order on the expectedChildren does not match the order on the children JSON object : exprectedChildren = [ .git, folder, test.txt] children -> [.git, test.txt, folder] GitUriTest#testGitUrisInContentLocation: this failure is similar to the first, the expectedChildren are [ .git, folder, test.txt ], but the children JSON objects are in the order [ .git, test.txt, folder ]. Everything else is passing on my local machine. I don't see anything in the logs on the server about the failures. I could if necessary attempt to debug the tests directly on the build server, let me know if you want me to do this.
(In reply to comment #2) > GitCloneTest#testCloneAndLink: I think this is just a problem with the test, (...) > GitUriTest#testGitUrisInContentLocation: this failure is similar to the first, (...) I've fixed these two with 2814fd6d925e572b1870563e7b50628ae4b0dedc. Apparently, children order is platform dependent, and running tests on Win and Linux wasn't enough to catch it. > I could if necessary attempt to debug the tests directly on the build server, let me know > if you want me to do this. It looks that the git API doesn't recognize passed content locations[1] as valid git repositories. If you could set a breakpoint somewhere in org.eclipse.orion.server.tests.servlets.git.GitDiffTest.testNoDiff() and see if gitDir points to a git repository that would be great. [1] org.eclipse.orion.server.tests.servlets.git.GitTest.createProjectWithContentLocation(URI, String, String)
(In reply to comment #3) > It looks that the git API doesn't recognize passed content locations[1] as > valid git repositories. If you could set a breakpoint somewhere in > org.eclipse.orion.server.tests.servlets.git.GitDiffTest.testNoDiff() and see if > gitDir points to a git repository that would be great. gitDir is something like this: build:/tmp/31901743827> ls -la total 88 drwxrwxr-x 4 e4Build users 4096 2011-02-28 13:18 . drwxrwxrwt 326 root root 69632 2011-02-28 13:18 .. drwxrwxr-x 2 e4Build users 4096 2011-02-28 13:18 folder drwxrwxr-x 7 e4Build users 4096 2011-02-28 13:18 .git -rw-rw-r-- 1 e4Build users 4 2011-02-28 13:18 test.txt This looks fine, however a breakpoint in GitFileDecorator#addAttributesFor is not getting hit during the test. I haven't gotten access to an osgi console for the running tests, but I suspect that the bundle org.eclipse.orion.server.git has not been activated, so the GitFileDecorator service has not been registered yet. Note the difference between self hosting in eclipse and running the orion server is that when self hosting, all bundles are automatically started, but in the server, bundles being started must be explicitly listed. We probably need to use DS in this bundle, or else add it to the product's list of explicitly started bundles.
Thanks a lot Andrew, this is really helpful. I will investigate that as soon as I'm done[1] with most of the blockers of bug 336116 scheduled for 0.2M6. Until then I'm removing git server tests from AllServerTests suite[2], but I will keep running the tests locally. [1] probably 0.2M7 [2] 78554b3a8e66081f11b765047b02beab704aa28a
I have added org.eclipse.orion.server.git to the list of bundles being automatically started in the server.
(In reply to comment #6) > I have added org.eclipse.orion.server.git to the list of bundles being > automatically started in the server. Thanks Andrew. It should solve the problem. We'll see for sure when the tests are finished during he next build.
I enabled Git tests.
We are now down to 4 failing tests, all fail with expected:<201> but was:<500> If it is relevant, there was a single line output to the console while running the tests: [java] Could not read ssh properties file: null
(In reply to comment #9) > We are now down to 4 failing tests, all fail with > expected:<201> but was:<500> These are being tracked by bug 338793. > If it is relevant, there was a single line output to the console while running > the tests: > [java] Could not read ssh properties file: null This is a property file I'm using locally to run cloning over ssh. I don't think there are in the state to be run on the server. If the file is missing the tests are ignored, so there's nothing to worry about.
The tests from this bug passed in N20110322000.
