-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds support for vanilla Gerrit #1954
Conversation
d911d45
to
4735b7e
Compare
7e9dcd2
to
2531553
Compare
I tested against both Google Source repositories and vanilla Gerrit repositories. Everything seems to be working as expected. Also, I don't think this is going to be a practical breaking change, as I doubt anyone had ever added custom Gerrit providers to their settings (because if they did, it didn't work, as the implementation to-date is only valid for Google Source, which should be covered by the existing regex -- and therefore would not require one to set a custom provider for it). |
6ffa581
to
dcc37f0
Compare
This is ready to review. /cc @andrewsavage1 as you have worked in the previous Gerrit provider. |
No issues with this from me, thanks for the fix @felipecrs. |
dcc37f0
to
b6ba826
Compare
@Levistator, @adambadura as you both reported similar issues, I would kindly ask if this would solve your issues. |
And separates the existing Gerrit provider to a new GoogleSource one. Closes gitkraken#1953
b6ba826
to
7350e8b
Compare
If you would like to test, I built a vsix that you can install in your VS Code: It's not a zip file, simply rename to remove the .zip suffix after downloading (GitHub only allows to upload certain extensions in comments). |
} | ||
|
||
private get reviewDomain(): string { | ||
const [subdomain, secondLevelDomain, topLevelDomain] = this.domain.split('.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW this doesn't work for domains with more than three levels.
e.g. project.git.source.company-tld.com
Can this just split and mutate the subdomain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only for GoogleSource. Are you sure this is applicable for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upon double-checking, I guess it's not strictly necessary.
The domain I was using also resolves with project.googlesource.com
I had to update my git config remote URL and restart VS Code, but it worked 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The domain I was using also resolves with project.googlesource.com
Not sure if I understood this part.
Anyway, after this PR, you would configure VS Code with:
"gitlens.remotes": [{ "domain": "project.git.source.company-tld.com", "type": "Gerrit" }]
@acarlson1029 If you have such an environment to test, I would advise you to test it before we merge. The .vsix is available here:
Is there any document describing how to use your package? Especially in remote scenarios? I'm sorry, but I'm new to Visual Studio Code. |
Turns out on the "Extensions" tab, in the "..." menu there is "Install from VSIX..." and it works as expected, including my remote work scenario. |
The issue #1787 (on adding However, my own issue #1902 is not closed. Now I have Or do I have to do some extra configuration in the plugin settings to have this covered? Interestingly, this could perhaps be deduced (or wild-guessed) from Git configuration itself. My
including also versions with |
For the record, my "gitlens.remotes": [
{"domain": "gerrit.ext.net.nokia.com", "type": "Gerrit"},
{"domain": "gerrit-wrsl1.int.net.nokia.com", "type": "Gerrit"}
], |
@adambadura Would you mind running: git remote -v From within your cloned project? |
Where I work, we have a comparable situation. But there is one thing weird in your case, the protocol is set as HTTPS, but the port 29148 (which is Gerrit's known SSH port). If my suspicious is correct, you are using SSH in the I have switched from SSH to HTTPS since a long time ago and I never looked back. With GCM, I don't need to re-type my password either. Perhaps it can work for you too, although I don't deny we can improve the extension to support such a mirror/master scenario. |
Sure:
|
@adambadura, I tested here, locally, and it seems to be working as expected. There is one point, however: {
"gitlens.remotes": [
{"domain": "gerrit.ext.net.nokia.com", "type": "Gerrit"},
],
} Do NOT add the mirror to the list of Gitlens Remotes. Can you please check if that works for you? Code_VbrM0yfowG.mp4 |
I will get back to you on this on Monday. |
Yep it works for me. Thanks @felipecrs !! |
Indeed, using only the main server: "gitlens.remotes": [
{"domain": "gerrit.ext.net.nokia.com", "type": "Gerrit"}
], helped in that the proper server is reached (at least from the However, as it turned out, this is not enough in my case. The server is OK, but the web access is done through
while the plugin makes it
I know this goes beyond what I described in #1902 and I would close #1902 with this one and open a more specific issue afterward. However, perhaps you do know already how to address this configuration? I did try using |
@adambadura what would be the Gitiles homepage for your server then?
Is it any of the above? As an example: |
It is the last one, although I had to add the trailing / as otherwise I was getting "Not Found" error. |
Got it. So, your Gerrit is running under a reverse proxy. That's a little odd, because the domain itself has Gerrit in its name, so I wonder what the need for such an extra identifier in the URI was. Anyway, this does not change the fact that you run through a reverse proxy, and ideally this should be supported. Having that said, it's a different feature than what this PR is trying to solve. So, I would suggest you open a different issue, targeting something like Support Git remote providers running behind a reverse proxy. I haven't checked, but I suspect this isn't only valid for Gerrit. I have some ideas on how that can be solved, but an issue would be helpful so that we could discuss with the maintainers the preferred approach. |
OK then, let's close #1902 along with this one. |
@eamodio just to say this is ready to review now. |
Wow, @felipecrs, this is awesome. Thank you so much for your contribution! And thank you to all the testers too! |
Description
I work with Gerrit every day, and today I realized how much time it could save if Gitlens worked for me. To my surprise, I found Gerrit in the list of supported providers, but when trying to use it, I stumbled upon some issues.
The current Gerrit provider implementation is very tied to Google Source, but Google Source is an implementation on top of the vanilla Gerrit, and many other orgs implements Gerrit in the vanilla way.
This PR turns the existing Gerrit provider into a generic/vanilla Gerrit one (not tied to Google Source), but adds back Google Source as its own provider, meant to be used in Android, Chromium, Gerrit itself, Golang, and other projects from them.
Also, the new provider comes with a new pre-configured domain, which is the GerritHub, a publicly known and freely available Gerrit instance.
Where I work, however, we host our own Gerrit instance, and I would configure Gitlens as follows:
Closes #1953
Closes #1787
Closes #1788
Closes #1902
Checklist
Fixes $XXX -
orCloses #XXX -
prefix to auto-close the issue that your PR addresses