Community
Participate
Working Groups
I've seen IndexDiffCacheTest fail on the server and locally with different test cases. I have this hypothesis: That test class stores only the _last_ indexDiffData that the listener saw. But there is no guarantee that we get only 1 event. Instead there might be multiple events and we need to collect the indexDiffData for all of them (that means waitForListenerCalled() must continue listening after the first received data until there is no more data received for some time). Example: org.eclipse.egit.core.internal.indexdiff.IndexDiffCacheTest.testAddFileFromUntrackedFolder() That one fails locally in line 127, because the _first_ event does not contain the expected added data. But a second event contains it. Does that make sense to anyone (since I really have no idea of the underlying git mechanics for indexdiff)?
This test has not been unstable in the past. I suspect the changes from the parallel pull to be responsible for this. Possibly https://git.eclipse.org/r/#/c/131572/9/org.eclipse.egit.core/src/org/eclipse/egit/core/internal/indexdiff/IndexDiffCacheEntry.java .
So do you think this needs some fix in the main code or is the fix in the test code as desribed above reasonable? Cause I imagine I can rework the test to cope with multiple events, but I have no clue about the main code.
IndexDiffCacheEntryTest is not the only test case affected by this. I strongly suspect that other failures we see recently are also caused by this: * TagActionTest.testChangeTagMessage https://ci.eclipse.org/egit/job/egit/4945/ * GitRepositoriesViewBranchHandlingTest.testCreateCheckoutDeleteLocalBranch https://ci.eclipse.org/egit/job/egit/4947/ And possibly more.
