Automatically detect Gerrit server URL and credentials

[leoluk]

Problem Statement:

• Many users are using more than one Gerrit server. A common example is googlesource.com, which runs one instance for every project (Chromium, Fuchsia, Go, Cuelang, Gerrit itself...). The Gerrit plugin config is global and only one server can be specified, so one would need multiple IntelliJ profiles to work with multiple servers.

• HTTP Credentials are sometimes short-lived and expire within hours to days. Setups that do this also provide means to automatically refresh them in Git's credential store (typically via .git-credentials or .gitcookies). To use these credentials with the plugin, they need to be plucked from the respective config files and entered into the UI.

Proposed Solution:

Add an optional auto-discovery feature which attempts to read Gerrit connection config and credentials from the environment at startup or whenever authentication fails, and fall back to the configured default Gerrit server if none are found.

• Read the Gerrit URL by from codereview.cfg in the current project root: https://pkg.go.dev/golang.org/x/review/git-codereview#hdr-Configuration (this is as close to a standard as it gets, not aware of any other).

• Run git credential fill in the project's root directory to acquire credentials for the Gerrit server (https://git-scm.com/docs/git-credential). This uses Git's existing secrets management machinery, which can be anything from a simple ~/.git-credentials file to a daemon which interacts with the system password store.

• .gitcookies as used by googlesource.com are a bit of an oddball special case. In the case of googlesource.com, the cookie just happens to contain valid Gerrit credentials (I think they have a special Git proxy in front of Gerrit which understands the cookie). Not sure why Google isn't using the git-credentials mechanism here - perhaps because it's not guaranteed to be functional without extra config? We would need to look for googlesource.com cookies and parse them.

Unclear:

• Are background notifications global or tied to a specific open project? I disable them anyway, but if they're global it should be fine to just always use the default server?

Related issues:

• 159 (per-project settings - would solve this problem, but inconveniently - credentials would have to be re-entered for every project, and some Gerrit servers host many projects)

• 382 (a pending PR that implements per-project settings, but isn't making progress + would require re-entering credentials for different projects rather than having a global list of servers)

• 365 (closed .gitcookies feature request)

This an RfC, not a feature request - we're willing to spend the money and/or time needed to get this implemented, but want to create an issue first to make sure this is a contribution you would be willing to accept.

[uwolfer]

Hi @leoluk

Thank you very much for this well structured issue! I basically fully agree that we should make the plugin multi-gerrit-project capable.

Let's start with some questions:

HTTP Credentials are sometimes short-lived and expire within hours to days.

Do you have examples of such Gerrit setups? I think I've never come across such a setup.

codereview.cfg

Is this a file which can be added to the Git repo and be shared with other project members?

git credential fill

Does this work out of the box for example against googlesource.com Gerrit instances? Or is there some setup required?

Are background notifications global or tied to a specific open project?

I'd say by default these notification should be bound to the currently opened project (there is a setting for this in the plugin, and we could respect that).

I think it would help if you could shortly describe the flow how to setup a new Gerrit project (e.g. a gerrit-review.googlesource.com) in IntelliJ using the tooling / config described in your suggestion.

[leoluk]

Do you have examples of such Gerrit setups? I think I've never come across such a setup.

I know of one internal instance which works like that and uses an OAuth client to fetch new credentials. Might be a fringe use case, but it's possible (and reasonable) to implement this using a Gerrit plugin.

Even if tokens do not expire, it would still make it easier to onboard new contributors (a few less clicks to do).

Is this a file which can be added to the Git repo and be shared with other project members?

Yes, that's the idea - many of Google's Gerrit-hosted projects have one, for example. It originated with the Go project, I think. It has a couple of other useful fields like default remote branch name for review, and upstream branch for feature branches.

Perhaps the presence of a codereview.cfg could even be used to toggle the "Push to Gerrit by default" flag?

Does this work out of the box for example against googlesource.com Gerrit instances? Or is there some setup required?

Unfortunately, no - it works with everything except googlesource.com instances, who use the weirdo .gitcookies mechanism.

I think it would help if you could shortly describe the flow how to setup a new Gerrit project (e.g. a gerrit-review.googlesource.com) in IntelliJ using the tooling / config described in your suggestion.

Here's three particular workflows I have in mind:

Magic googlesource.com SSO

• git clone from googlesource.com (an experienced user would use the magic incantation from Gerrit that adds the commit-hook, otherwise they'd be prompted on first push with the same result).
• SSO login via https://www.googlesource.com/new-password (copy&paste a code snippet which populates ~/.gitcookies).
• Opening the project in IntelliJ would have the Gerrit plugin working without extra config.

HTTP Password workflow

• git config credential.helper store (either globally or for the project)
• Log into Gerrit web UI, copy password.
• git clone, enter credentials, they get stored.
• Open in IntelliJ, everything works!

Company SSO wizardry

• Run company tool that acquires token via OAuth and puts it into ~/.git-credentials magically. Do so every morning because the tokens expire.
• git clone
• Open in IntelliJ, everything works

[uwolfer]

Thanks for the explanations, makes sense to me so far.

When I read this approach, IntelliJ EditorConfig support comes to my mind: once there is a .editorconfig file in your project, it will overrule code style settings set in IntelliJ settings. I like this idea, as it also simplifies IDE setup for new project members and it will also be fully backwards compatible for existing users (things will only change once there is a codereview.cfg available).

HTTP Password workflow

Does this also assume that you do a git clone via https? Does it also work when you use ssh?

git clone

The Gerrit IntelliJ plugin also support cloning directly from the IDE, which also populates the commit-hook. I think your approach would also work this way?

[leoluk]

Does this also assume that you do a git clone via https? Does it also work when you use ssh?

Yep - Git clone would be done via https as well, using the same credentials. With SSO environments, users typically do not have their own long-lived SSH keys (like with googlesource.com).

The Gerrit IntelliJ plugin also support cloning directly from the IDE, which also populates the commit-hook. I think your approach would also work this way?

Yep, that would work the same