Community
Participate
Working Groups
Steps: 1. Create Gerrit repository as anonymous 2. Update repository configuration 3. Open repository settings and enter credentials 4. Validate The message is "Logged in as null".
Related / cause-of bug 410597?
(In reply to comment #1) > Related / cause-of bug 410597? I don't know. I am assuming that cached state in the connector is not properly discarded when repository properties change which is causing this defect. It doesn't necessarily need to be related to bug 410597.
Postponing to 2.1 for now.
See also bug 412098 for a different issue with repo validation.
*** Bug 412098 has been marked as a duplicate of this bug. ***
Fixed by: https://git.eclipse.org/r/#/c/14294/ Please verify. Candidate for possible inclusion in 2.0.1. Actually, I think it was the same cause. I'm not sure given description, but it's even possible that Steffen had a valid connection, but it wasn't being reported because the Account full name was returning null even though a user exists for the Gerrit Tests. In addition to fixing that issue, this change clarifies and simplifies the interface, allowing explicit resetting of connection.
Miles, what in review 14429 would fix this problem? Could isolate that particular change and provide a test case?
(In reply to comment #7) > Miles, what in review 14429 would fix this problem? Could isolate that > particular change https://git.eclipse.org/r/#/c/14294/12/org.eclipse.mylyn.gerrit.ui/src/org/eclipse/mylyn/internal/gerrit/ui/GerritRepositorySettingsPage.java > provide a test case? https://git.eclipse.org/r/#/c/14294/12/org.eclipse.mylyn.gerrit.tests/src/org/eclipse/mylyn/gerrit/tests/core/client/GerritClientTest.java
We can improve GerritSystemInfo.getFullName() with the change you are proposing and maybe you are right that that was the actual problem. The client tests look good but they don't really test the validation scenario since the life-cycle of the client is managed in the connector in that case where I was suspecting the bug but from looking at the code I don't see anything obviously wrong. Are you if I take your change and rebase the two classes you pointed out against the latest master?
(In reply to comment #9) > Are you if I take your change and rebase the two classes you pointed out against > the latest master? Totally. :) I can do that to. I'm not wedded to any particular approach here, it just probably doesn't make sense for Tomek and I to be in the same code at the same time.
(In reply to comment #9) > We can improve GerritSystemInfo.getFullName() with the change you are proposing > and maybe you are right that that was the actual problem. > > The client tests look good but they don't really test the validation scenario > since the life-cycle of the client is managed in the connector in that case > where I was suspecting the bug but from looking at the code I don't see anything > obviously wrong. What I was seeing and the reports that we were getting were that we were having difficulties when users first logged in (or didn't) and then subsequently made a change. It seemed that configuraiton changes weren't taking. The tests were designed to ensure that the configuration change actually got made. I found the code as written quite opaque to the extent that I couldn't understand even what was suppossed to be happening, which is what drove me to refactor it as I did.
I'm reassinging to default. Let's discuss how we want to cover this one and bug 410597.
I committed a fix for the username problem in 604edce1d17845034a9f10dcd19a698d772bde30 and updated the summary accordingly. It's not clear to me whether there are other problems beyond that. Please open separate bugs for any outstanding issues.
