Migration of JGit and EGit to GerritHub/GitHub

mentioned in issue #680

changed the description

Thanks! I appreciate the work on ensuring there's continuity of hosting for EGit and JGit.

One thing I'd wonder is, would hosting on gerrit-review.googlesource.com be another option? The reasons I ask are the close relationships in projects with Gerrit and the possibility of using infrastructure such as LUCI that exists for that host.

On the other hand, GerritHub has the advantage of being something that can work for all Eclipse projects that want to use Gerrit, instead of just Gerrit-project-adjacent ones.

If Google offers to host our repos, and you can import the existing JGit and EGit repos so that we can still see old reviews and run the ECA plugin which checks if contributors have signed the Eclipse Contribution Agreement this would be another option.

I guess we would still need to replicate the repos to GitHub like GerritHub does, to ensure that the Eclipse Foundation doesn't need to establish another backup mechanism which AFAIK they have in place for their github.com organizations and gitlab.eclipse.org.

Not sure how committer permission assignments would work on gerrit-review. GerritHub uses Github accounts and AFAIK the Eclipse Foundation owns their project's Github organizations and they have that integrated with their systems to know which users are committers.

Thanks much, this is helpful. Gerrit supports custom group backends so it would be possible for googlesource.com to get the list of committers from another source (or, for example, some other infrastructure could sync it to a Google Group), but I'm not aware of that already being set up. Similarly, it would need to get the ECA group that gerrit-eca-plugin depends on.

Within these constraints, migrating to GerritForge seems like a smoother path; it would also be more consistent with other Eclipse projects.

The relationship between JGit and Gerrit leaves me feeling some aspects still unresolved, but we can figure those out on a longer timeline. In other words, it sounds like the right thing to do now is still to migrate to GerritHub, but I'd like to keep the door open to migrating again at a later point due to the long term benefits it could provide with proximity to the Gerrit project.

added Migration label

Could you provide an answer on the first two questions regarding usage of the domain name eclipse.gerrithub.io and regarding the ECA plugin calling your ECA check API ?

With that we could continue preparations on GerritHub side.

@mward @droy can you comment on this?

I've asked @wbeaton for ECA and such legalese guidance.

closed

reopened

I'm not concerned about the subdomain.

GerritHub would fall under our definition of an external resource. Its use is not supported by the Eclipse Foundation IT team, but as long as it doesn't impact our ability to continue our existing practices that support the EDP and Eclipse Foundation IP Policy, it should be okay.

I'll reinforce that the EF-managed GitHub repository must be kept up-to-date

I am concerned about the additional barriers for entry that this might add. Do contributors need to have a GerritHub account? What information do they have to give up in order to interact with the service?

Who owns the data in Gerrit? Who controls who has what privileges in GerritHub?

I'm also concerned about additional requirements that this may put on the infrastructure team. But I'll defer discussion of that to them.

Do contributors need to have a GerritHub account?

In general, any GitHub user is potentially a GerritHub user as well: the authentication is done through OAuth and the user decides the level of visibility of GerritHub on its data.

All GitHub identities are GerritHub identities as well. There isn't a GerritHub account that isn't a GitHub.

In addition, any GitHub PR can be imported into GerritHub, without the PR author being forced to login to GerritHub at all. That allows the JGit maintainers to keep a formal code-review process without putting any additional barrier to the contributors.

P.S. I assume that the current JGit contributors know already how to use Gerrit Code Review, so that shouldn't a barrier to contributions for them.

Who owns the data in Gerrit? Who controls who has what privileges in GerritHub?

The JGit project owner (JGit maintainers) are managing the ACLs of the JGit project on GerritHub. Everything, including reviews, that is authored on GerritHub.io is 100% replicated back to GitHub.

I'm also concerned about additional requirements that this may put on the infrastructure team. But I'll defer discussion of that to them.

Happy to have a conference with them if they would need any further input. There are successful GitHub projects that use GerritHub.io for their code-reviews:

Cue uses GerritHub.io and GitHub actions for their CI/CD pipeline (https://youtu.be/2B2PZTZlPJg)
NFS Ganesha (https://github.com/nfs-ganesha/nfs-ganesha)
OpenStack Infrared (https://github.com/redhat-openstack/infrared)
CEA High Performance Computing (https://github.com/cea-hpc)
RedHat Open Infrastructure (https://github.com/rhos-infra) ... and other 300+ projects so far.

@wbeaton things are getting ready for JGit/EGit on https://eclipse.gerrithub.io. Would you like to involve your infrastructure Team for setting up the CI/CD (Gerrit Trigger Plugin) pointing to GerritHub.io?

Hi! security guy here. I have several concerns/questions:

Current setup https://eclipse.gerrithub.io/ has the GerritCodeReview/jgit repo https://eclipse.gerrithub.io/q/project:GerritCodeReview/jgit+status:open which seems to be linked to https://github.com/GerritCodeReview/jgit. Do you confirm that this is only temporary / for testing purpose and that eventually, the jgit GH canonical repo would be github.com/eclipse-jgit/jgit (with EF as the single owner) if we pursue in this direction?
To fix vulnerabilities, projects on GH can use temporary private fork. We plan on promoting its usage to help projects with dealing with vulnerability reports. How does it work with GerritHub?
What happens if we configure a branch protection rule requiring a PR or status checks to pass before merging? What about requiring signed commits?

Finally, about CI/CD, I strongly advise to move to GH branch source plugin and to stop using the Gerrit Trigger Plugin as soon as the sources are available on GH. Gerrit trigger plugin triggers builds without any check for user permissions. Any external contribution triggers a build, which means that any malicious code can be executed as a result. Moving to GH and embracing GH PR is hugely beneficial from the security PoV.

The current setup with github.com/GerritCodeReview/jgit on GH is for temporary testing until we get approval, when the productive repo is migrated from git.eclipse.org to eclipse.gerrithub.io it will be linked to github.com/eclipse-jgit/jgit which needs to be created during the migration
we will draft a detailed migration plan next week
so far we worked on security fixes on a private fork of the jgit repo on https://gerrit-review.googlesource.com/ where only jgit maintainers working on security fixes have access, we could also do the same on eclipse.gerrithub.io
Gerrit has a more fine grained permission model [1] than GH and provides extensible submit requirements [2] which control when a change is submittable
Gerrit supports signed pushes [3]. JGit so far supports signed tags. For signed commits we would first need to implement support in JGit and add an option to Gerrit to validate them. If that's an upcoming requirement we can do that. Most of the JGit committers are also Gerrit maintainers :-)
I doubt that the GH branch source plugin knows how to trigger builds for new patchsets in Gerrit which aren't based on temporary feature branches but on change refs. We already plan to enhance the gerrit-trigger plugin to support triggering builds based on messages from a message broker (aiming for Google PubSub). We can also consider to contribute a mechanism that requires approval from a committer before a validation build is triggered to prevent execution of malicious code. I can discuss this with our Jenkins expert.
[1] https://gerrit-review.googlesource.com/Documentation/access-control.html
[2] https://gerrit-review.googlesource.com/Documentation/config-submit-requirements.html
[3] https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#receive.enableSignedPush

We can also consider to contribute a mechanism that requires approval from a committer before a validation build is triggered to prevent execution of malicious code. I can discuss this with our Jenkins expert.

Ideally, it should mimic what GH branch source offers, and offer the possibility to configure the builds to be triggered automatically only when the patchset has been pushed by someone with push or submit permission to the repo.

We can adopt the Gerrit Code Review plugin [4] (the equivalent for Gerrit of the GitHub branch source) which allows to specify a specific query for running the builds on incoming changes. That would allow to specify a "Ready for CI" label with an ACL for committers only. This would ensure that builds are only triggered when a committer set the "Ready for CI" label.

[4] https://plugins.jenkins.io/gerrit-code-review/

I like the sound of that!

I have to correct myself: JGit supports PGP signing of commits since 5.11.0.202103091610-r, see https://git.eclipse.org/r/c/jgit/jgit/+/175331

Could we agree on a timeline for this migration ? Holiday season is around the corner, I will be in vacation calendar week 32-34.

Could we get this migration to GerritHub/GitHub done after 2023-09 is out ?

added team:infra label

We can certainly work with that timing. How about we aim to do the move on October 3rd?

I checked with Luca from GerritForge, migrating on October 3rd would work for us.

Can we move the migration date to the week after EclipseCon ? We still need to sort out what needs to be done for the CI.

To prepare the migration could you already do the following preparations ?

create empty repos on github:

eclipse-jgit/jgit
eclipse-jgit/jgit-pipelines (new one, need to also version CI jobs for jgit)
eclipse-egit/egit
eclipse-egit/egit-github
eclipse-egit/egit-pipelines

For gerrithub.io we need a technical github user (I guess Eclipse would prefer one per Eclipse project) with push permission for replication to the repos on github and read access to the committer teams on github:

github.com/eclipse-jgit
github.com/eclipse-egit

and a technical github user for each CI which we can grant the necessary permission in gerrithub.io so that the jobs can vote on changes

There are already github teams for the respective project committers which we need to assign committer permissions on gerrithub.io

there are also teams for project leads

added IT-prioritylow IT-severitylow team:releng labels

added ~16280 statetodo labels

assigned to @heurtemattes

assigned to @chills2023

changed due date to October 23, 2023

@msohn a due date has been set for October 23

In addition, it sounds like a good opportunity to enable self-service (https://www.eclipse.org/projects/handbook/#resources-github-self-service) for your project at GitHub. This will capture the existing configuration as code in a separate repo (.eclipsefdn) and any committers can create PRs against this repo to change the configuration to fit your needs. The PRs will need to be approved by EF staff (and project leads if needed) before being merged and the changes finally being applied to GitHub. Here is for example a PR from another project enabling consistent branch protection rules for all repos: https://github.com/eclipse-velocitas/.eclipsefdn/pull/1 Here you can see a list of all Eclipse project that have this already enabled: https://eclipsefdn.github.io/otterdog-configs/ If you agree, we will make all preparation and create the first PR for demonstration purposes and also provide help for any questions that may arise.

I agree, this self-service for GitHub seems useful, please enable it for JGit and EGit.

Was the self-service enabled ? Can we start using it to prepare the migration planned for next week ?

Not yet. I'll work on it this week.

Self-service has been activated on both organization.

Both bots have been created and added to each jenkins instance.

Webhook were set on each github organization.

marked this issue as related to eclipsefdn/security/otterdog#122 (closed)

marked this issue as related to eclipsefdn/security/otterdog#123 (closed)

The empty repos on github have been created to prepare the migration:

We need some technical Github users:

one for GerritHub to replicate to GitHub (needs force push access on the github repos in the eclipse-jgit and eclipse-egit github organisations), I got the public key of the ssh key pair GerritHub is using to push changes to the eclipse-jgit and eclipse-egit orgs on Github
another one for each CI (https://ci.eclipse.org/jgit/, https://ci.eclipse.org/egit/) to listen on events raised by GerritHub and vote on changes in GerritHub, these users need ssh keys to listen on ssh stream events of GerritHub

We need to decide if we want to have Gerrit permission projects the actual dev repos inherit permission settings from. Similar to https://git.eclipse.org/r/admin/repos/permissions/jgit-dev,access and https://git.eclipse.org/r/admin/repos/permissions/egit-dev,access

We can use GitHub teams as groups in GerritHub, so we can assign GerritHub permissions to GitHub teams to map who is a committer, a CI system or Eclipse staff. Also GerritHub uses GitHub for authentication.

Do we want another permission project to mimic the root permission settings defined in https://git.eclipse.org/r/admin/repos/All-Projects,access ? On GerritHub we don't control All-Projects since that's owned by GerritForge administrating the complete service.

Other users (committers and contributors) should have no write permissions on the github repos and PRs should be disabled. The general workflow is that users push changes for review to GerritHub the Gerrit way, code review happens in Gerrit and GerritHub replicates everything to GitHub to keep the repos in GerritHub and GitHub in synch. This replication will start to work as soon as the replication user mentioned above has forced push permissions on the repos in GitHub.

In addition, at the moment there's a cronjob running which replicates everything happening on the jgit and egit repos on git.eclipse.org to eclipse.gerrithub.io to ensure we migrate all the existing changes to GerritHub.

one for GerritHub to replicate to GitHub (needs force push access on the github repos in the eclipse-jgit and eclipse-egit github organisations), I got the public key of the ssh key pair GerritHub is using to push changes to the eclipse-jgit and eclipse-egit orgs on Github

I wonder how this replication will take place. Is it a gerrithub feature? If you can provide some useful links. Or maybe a CI/cron job that needs to be implemented?

another one for each CI (https://ci.eclipse.org/jgit/, https://ci.eclipse.org/egit/) to listen on events raised by GerritHub and vote on changes in GerritHub, these users need ssh keys to listen on ssh stream events of GerritHub

I connected both bots to gerrithub and configured their public key: eclipse-jgit-bot and eclipse-egit-bot. I have some work to be done with the jenkins instance in order to configure a new server with these new keys.

If you can add these bots to each project on gerrithub by replicating github permission. I hope this will be enough to allow replication.

NOTE: each bots are part of each github commit team: technology-egit-committers and technology-jgit-committers

We need to decide if we want to have Gerrit permission projects the actual dev repos inherit permission settings from. Similar to https://git.eclipse.org/r/admin/repos/permissions/jgit-dev,access and https://git.eclipse.org/r/admin/repos/permissions/egit-dev,access

If possible, yes.

We can use GitHub teams as groups in GerritHub, so we can assign GerritHub permissions to GitHub teams to map who is a committer, a CI system or Eclipse staff. Also GerritHub uses GitHub for authentication.

Sounds good! Can you configure this?

Do we want another permission project to mimic the root permission settings defined in https://git.eclipse.org/r/admin/repos/All-Projects,access ? On GerritHub we don't control All-Projects since that's owned by GerritForge administrating the complete service.

As much as possible! Sounds like good best practices.

Other users (committers and contributors) should have no write permissions on the github repos and PRs should be disabled. The general workflow is that users push changes for review to GerritHub the Gerrit way, code review happens in Gerrit and GerritHub replicates everything to GitHub to keep the repos in GerritHub and GitHub in synch. This replication will start to work as soon as the replication user mentioned above has forced push permissions on the repos in GitHub.

Sounds like more tricky. We use a sync batch between PMI (committers and project leads definition) and github with specific permission set for all eclipse github organization.

NOTE: PR is a core feature of github and can't be disable directly but as a workaround reducing scope permission for user might work.

one for GerritHub to replicate to GitHub (needs force push access on the github repos in the eclipse-jgit and eclipse-egit github organisations), I got the public key of the ssh key pair GerritHub is using to push changes to the eclipse-jgit and eclipse-egit orgs on Github

I wonder how this replication will take place. Is it a gerrithub feature? If you can provide some useful links. Or maybe a CI/cron job that needs to be implemented?

That's done using the Gerrit replication plugin which is installed on GerritHub. Luca configured it with a dedicated ssh key pair for replication to GitHub.

another one for each CI (https://ci.eclipse.org/jgit/, https://ci.eclipse.org/egit/) to listen on events raised by GerritHub and vote on changes in GerritHub, these users need ssh keys to listen on ssh stream events of GerritHub

I connected both bots to gerrithub and configured their public key: eclipse-jgit-bot and eclipse-egit-bot. I have some work to be done with the jenkins instance in order to configure a new server with these new keys.

If you can add these bots to each project on gerrithub by replicating github permission. I hope this will be enough to allow replication.

The CI bots aren't involved in replication. We need to manually grant them voting permission on the GerritHub side using Gerrit permissions so that they can vote on changes in review depending on build and test results. Permissions cannot be replicated from github to GerritHub since the permission models of Gerrit and GitHub are pretty different.

We need to decide if we want to have Gerrit permission projects the actual dev repos inherit permission settings from. Similar to https://git.eclipse.org/r/admin/repos/permissions/jgit-dev,access and https://git.eclipse.org/r/admin/repos/permissions/egit-dev,access

If possible, yes.

ok, then I'll request another repo jgit-permissions and egit-permissions via otterdog and import them into GerritHub as soon as they have been created. Then we can configure Gerrit permissions on the GerritHub side of the house.

We can use GitHub teams as groups in GerritHub, so we can assign GerritHub permissions to GitHub teams to map who is a committer, a CI system or Eclipse staff. Also GerritHub uses GitHub for authentication.

Sounds good! Can you configure this?

yes, I can do this as soon as the permission repos have been created.

Do we want another permission project to mimic the root permission settings defined in https://git.eclipse.org/r/admin/repos/All-Projects,access ? On GerritHub we don't control All-Projects since that's owned by GerritForge administrating the complete service.

As much as possible! Sounds like good best practices.

In which github org should that repo be located eclipse-jgit or eclipse-egit or another generic one ?

Other users (committers and contributors) should have no write permissions on the github repos and PRs should be disabled. The general workflow is that users push changes for review to GerritHub the Gerrit way, code review happens in Gerrit and GerritHub replicates everything to GitHub to keep the repos in GerritHub and GitHub in synch. This replication will start to work as soon as the replication user mentioned above has forced push permissions on the repos in GitHub.

Sounds like more tricky. We use a sync batch between PMI (committers and project leads definition) and github with specific permission set for all eclipse github organization.

NOTE: PR is a core feature of github and can't be disable directly but as a workaround reducing scope permission for user might work.

It's not a big problem if PRs cannot be disabled completely, they can be imported by committers one-way from GitHub to a new Gerrit change in GerritHub but review has to happen there hence I thought it would be easier to understand if PRs are disabled and contributors only use the Gerrit workflow which they are used since 2010 :-)

I requested the permission repos

There are some ideas to deal with PRs. You could add a workflow that automatically closes any PR that gets opened. You could add a branch protection rule that expects a status check that always fails. We can certainly discuss that once the replication with gerrithub is up and running. I am curious how this is going to work.

btw. I fixed the webhook for the eclipse-egit organization, it was defined for the .eclipsefdn repo which does not make any sense. I changed it to an organization webhook as we usually do.

Do we want another permission project to mimic the root permission settings defined in https://git.eclipse.org/r/admin/repos/All-Projects,access ? On GerritHub we don't control All-Projects since that's owned by GerritForge administrating the complete service.

As much as possible! Sounds like good best practices.

In which github org should that repo be located eclipse-jgit or eclipse-egit or another one ?

We could name this repo e.g. "eclipse-permissions" or "Eclipse-All-Projects". WDYT ?

not ideal, but each org is independent, so I preferred create a new repo in each org.

Is there a way to mix those permissions in the same repository as jgit-permissions/egit-permissions?

yes, we can merge these global permission settings into jgit-permissions and egit-permissions, though it creates some duplication. If we put them into a separate repo the org specific permissions in jgit-permissions and egit-permissions can inherit them avoiding this duplication.

That's done using the Gerrit replication plugin which is installed on GerritHub. Luca configured it with a dedicated ssh key pair for replication to GitHub.

Ok, but these key pair is not allowed to push to github, I have to put the public key in the bot profile instead of the one I created and even for the jenkins gerrit-trigger plugin I need the private key. Can you send it to me in a secure way? gpg email or bitwarden.

The CI bots aren't involved in replication. We need to manually grant them voting permission on the GerritHub side using Gerrit permissions so that they can vote on changes in review depending on build and test results. Permissions cannot be replicated from github to GerritHub since the permission models of Gerrit and GitHub are pretty different.

Using same bot for replication and CI is fine. Can you set this specific permission to each bot?

NOTE: I see in our JIPP script related to gerrit that we also need to add CI bots to a particular group Event Streaming Users, it's related to gerrit jenkins plugin. But jenkins gerrit-trigger plugin shows this warn on the previous gerrit version <3.3, and gerrithub version is 3.8.2. So I guess it's not relevant anymore.

It's not a big problem if PRs cannot be disabled completely, they can be imported by committers one-way from GitHub to a new Gerrit change in GerritHub but review has to happen there hence I thought it would be easier to understand if PRs are disabled and contributors only use the Gerrit workflow which they are used since 2010 :-)

Hope you will never get that kind of comment :-S https://github.com/nfs-ganesha/nfs-ganesha/pull/1019#issuecomment-1775517059

You mean we use the user "eclipse-jgit-bot" both for

voting on JGit changes
and for replication from GerritHub to GitHub ?
and similar "eclipse-egit-bot" for the EGit repos ?

How can I send you the public ssh key used for replication via bitwarden ?

I'll ask Luca how to grant access to the event stream to the CI bots and also add it to service users which have their own thread pool to stay out of the way of interactive users. GerritHub is already updated to Gerrit 3.9 RC0 so the warning from the trigger plugin shouldn't be applicable.

voting on JGit changes

and for replication from GerritHub to GitHub ?

Right!

and similar "eclipse-egit-bot" for the EGit repos ?

Exactly!

How can I send you the public ssh key used for replication via bitwarden ?

You can use bitwarden send feature, but you need to create an account, you can get a free one. https://vault.bitwarden.com/#/sends

Note: I'm not able to configure two github accounts with same public key. So I need two distinct public keys to configure each bot profile.

Shouldn't we then better use a separate generic user for the replication and separate keys for the CI bots ? This would avoid that we enable the CI to force push to GitHub.

Shouldn't we then better use a separate generic user for the replication and separate keys for the CI bots ?

I think it's fine to use only one generic bot per project, as we do for all eclipse project on github with a CI. Using same bot for gerrithub should not be a problem. We just have this "limitation" sets by github, but obvious for security reason, to not be able to set twice the same public key in different github account.

This would avoid that we enable the CI to force push to GitHub.

WDYM?

This would avoid that we enable the CI to force push to GitHub.

WDYM?

If we do this CI bot users have voting permissions in GerritHub (needed for validating changes) and forced push permission (needed to mirror changes from GerritHub to GitHub) for the repos in GitHub. That means theoretically a CI job could do forced pushes on the GitHub repos.

Replication from GerritHub to GitHub now works for eclipse-egit, content was replicated to https://github.com/eclipse-egit/egit :-)

I asked Luca to create another key pair for eclipse-jgit and provide us the keys.

Great!

I configured jgit bot with the pub key if you can give it a try.

Now, I will configure jenkins instances and the gerrit trigger plugin.

I configured and mounted on both instances the private key for configuring gerrit trigger plugin. I'm struggling now with the plugin configuration for: Hostname, Frontend url, ssh port, and maybe others.

Do you know how to configure these inputs with gerrithub.io?

Great, making progress :-)

Replication for jgit repos seems to work, we now have content in https://github.com/eclipse-jgit/jgit

This should give you an idea how to access repos in GerritHub:

https://eclipse.gerrithub.io/admin/repos/eclipse-jgit/jgit,general

hostname: eclipse.gerrithub.io
frontend url: https://eclipse.gerrithub.io/
ssh port: 29418
username:
- eclipse-jgit-bot for https://ci.eclipse.org/jgit
- eclipse-egit-bot for https://ci.eclipse.org/egit

To translate the Gerrit permission settings from

global Gerrit settings: https://git.eclipse.org/r/plugins/gitiles/All-Projects/+/refs/meta/config/project.config
settings for JGit repos: https://git.eclipse.org/r/plugins/gitiles/permissions/jgit-dev/+/refs/meta/config/project.config
settings for EGit repos: https://git.eclipse.org/r/plugins/gitiles/permissions/egit-dev/+/refs/meta/config/project.config

to permission settings in

I need to map the groups used on git.eclipse.org to GitHub teams/users for GerritHub:

"Administrators" -> GitHub group "eclipsefdn-releng", should this also include "eclipsefdn-security" ?
"Hudson" ->
- jgit: GitHub user "eclipse-jgit-bot"
- egit: GitHub user "eclipse-egit-bot"
"ldap/common" -> ?, which group of users does this represent on git.eclipse.org ?
"ldap/technology.jgit" -> GitHub group "technology-jgit-committers"
"ldap/technology.egit" -> GitHub group "technology-egit-committers"

Can you please login to https://eclipse.gerrithub.io/ once with each of the bot users "eclipse-jgit-bot" and "eclipse-egit-bot" ? That's needed to create Gerrit accounts for them.

ftr: the default branch for the jgit and egit repos has been switched to master after the mirror was correctly setup as requested.

@msohn I have an error while contacting gerrithub with ssh from the jenkins instance: error in libcrypto And no issue from my laptop.

Can you tell me which algorithm was use for key generation: rsa, ecdsa, ed25519, ...?

I think they use ed25519, see the public keys.

Can you provide the full error message ? Which version of openssh is installed on jenkins ?

I think they use ed25519, see the public keys.

My bad you're right!

I figured out what was the problem! A break line in the private certificate. :-S

Anyway! On jenkins instance, I can ssh to eclipse-jgit-bot@eclipse.gerrithub.io but getting an error for eclipse-egit-bot@eclipse.gerrithub.io

eclipse-egit-bot@eclipse.gerrithub.io: Permission denied (publickey).

And in both jenkins instance, I have the same error:

2023-10-26 09:46:23.361+0000 [id=59] SEVERE c.s.t.g.g.GerritConnection#connect: Could not connect to Gerrit server! Host: eclipse.gerrithub.io Port: 29418
2023-10-26 09:46:23.362+0000 [id=59] SEVERE c.s.t.g.g.GerritConnection#connect: Proxy:
2023-10-26 09:46:23.362+0000 [id=59] SEVERE c.s.t.g.g.GerritConnection#connect: User: eclipse-jgit-bot KeyFile: xxxxxxxxxxxxxxxxxxxxxx
2023-10-26 09:46:23.362+0000 [id=59] SEVERE c.s.t.g.g.GerritConnection#connect: IOException:
com.jcraft.jsch.JSchException: Auth fail for methods 'publickey'
at com.jcraft.jsch.Session.connect(Session.java:499)
at com.sonymobile.tools.gerrit.gerritevents.ssh.SshConnectionImpl.connect(SshConnectionImpl.java:196)

I keep digging

Can't find the reason why it's not working with jenkins, but while testing directly bots with gerrithub, I have strange behaviours.

egit

ssh -o PreferredAuthentications=publickey -o HashKnownHosts=no -o IdentitiesOnly=yes -i id_rsa -p 29418 eclipse-egit-bot@eclipse.gerrithub.io
eclipse-egit-bot@eclipse.gerrithub.io: Permission denied (publickey).

=> don't work

git clone "ssh://eclipse-egit-bot@eclipse.gerrithub.io:29418/eclipse-egit/egit"

eclipse-egit-bot@eclipse.gerrithub.io: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights

=> don't work

But cloning with eclipse-jgit-bot works!

git clone "ssh://eclipse-jgit-bot@eclipse.gerrithub.io:29418/eclipse-egit/egit"

=> work!

jgit

ssh -o PreferredAuthentications=publickey -o HashKnownHosts=no -o IdentitiesOnly=yes -i id_rsa -p 29418 eclipse-jgit-bot@eclipse.gerrithub.io


 ****    Welcome to Gerrit Code Review    ****

  Hi eclipse-jgit-bot, you have successfully connected over SSH.

  Unfortunately, interactive shells are disabled.
  To clone a hosted Git repository, use:

  git clone ssh://eclipse-jgit-bot@review.gerrithub.io:29418/REPOSITORY_NAME.git

=> Seems to work!

git clone "ssh://eclipse-egit-bot@eclipse.gerrithub.io:29418/eclipse-jgit/jgit"

=> Don't work, but that's the configuration on https://eclipse.gerrithub.io/admin/repos/eclipse-jgit/jgit,general (ssh tab), which should show eclipse-egit-bot

git clone "ssh://eclipse-jgit-bot@eclipse.gerrithub.io:29418/eclipse-jgit/jgit"

=> works! normal with the right user

Can you check repos configurations, permissions?

I still have to configure permissions, didn't have time during the day. Will look into this later tonight.

Did you once logon to eclipse.gerrithub.io using the bot users and upload their public key to their GerritHub account under https://eclipse.gerrithub.io/settings/#SSHKeys ?

Could you answer my questions regarding groups which I asked above ?

I need to map the groups used on git.eclipse.org to GitHub teams/users for GerritHub:

"Administrators" -> GitHub group "eclipsefdn-releng", should this also include "eclipsefdn-security" ?
"Hudson" ->
- jgit: GitHub user "eclipse-jgit-bot"
- egit: GitHub user "eclipse-egit-bot"
"ldap/common" -> ?, which group of users does this represent on git.eclipse.org ?
"ldap/technology.jgit" -> GitHub group "technology-jgit-committers"
"ldap/technology.egit" -> GitHub group "technology-egit-committers"

Did you once logon to eclipse.gerrithub.io using the bot users and upload their public key to their GerritHub account under https://eclipse.gerrithub.io/settings/#SSHKeys ?

yes sure :-)

"Administrators" -> GitHub group "eclipsefdn-releng", should this also include "eclipsefdn-security" ?

Both please.

"ldap/common" -> ?, which group of users does this represent on git.eclipse.org ?

No idea, can you help on this @fgurr? you know better than me how git.eclipse.org works.

The rest looks good to me.

-i id_rsa

Why do you use an RSA key ? Didn't I send you an ed25519 key ? Depending on the used OpenSSH version SSH keys may be rejected on client side, see https://dev.to/cloudx/why-openssh-8-8-cannot-find-a-host-key-type-if-ssh-rsa-is-provided-49i

id_rsa is just a file name here.

I doubled checked what you tried and could reproduce that there is an issue with the egit keys, looks like public and private key don't match to each other. I asked Luca to check if he maybe sent wrong keys.

I checked if the eclipse-egit-bot keys match to each other and found they do match. You can compute the public key from the private key using

ssh-keygen -y -e -f <path to private key>

Maybe you uploaded the wrong public key to the gerrithub settings of the eclipse-egit-bot user or you use the wrong private key on the EGit Jenkins ?

This command only show me the jgit public key and not egit. Since we only have one private key, not sure we can get two distinct public keys from the same private key.

Looks like something went wrong with the transfer, I also have only one private key which seems wrong as it can't match 2 different public keys. Maybe I made a mistake when storing them in my keychain. I asked Luca to send me the keys again.

Luca sent me the keys for both bots again and I sent you Bitwarden links for accessing them via email/chat. I cross my fingers that they are now correct.

There are corrects, I have just finished to configure and redeploy them :-)

Now it seems the egit jenkins works

But I still have an issue with the jgit instance: Auth fail for methods 'publickey'

Luca sent the jgit key again and I tested it successfully, I updated it on Bitwarden

"ldap/common" -> ?, which group of users does this represent on git.eclipse.org ?

No idea, can you help on this @fgurr? you know better than me how git.eclipse.org works.

All committers (of all projects) are part of the ldap/common group.

added statewip label and removed statetodo label

I just had a call with Luca since I couldn't use GitHub teams in the eclipse-jgit and eclipse-egit github organisations to assign permissions in GerritHub. It turned out that I (and other JGit and EGit committers) need to have read access to the organisation otherwise GerritHub cannot read our membership in the technology-jgit-committers and technology-egit-committers. Could you grant these permissions to the committer teams ?

I now manually requested read access to the organisations: when you approve this I should be able to finish the configuration of Gerrit permissions which I started in the jgit-permissions repo.

I approved the request for egit and jgit, you should be able to complete the setup.

thanks a lot

@msohn Can you create relevant jenkins jobs configured for gerrithub.io with auth on both instance to test connectivities?

I created a job on egit instance, https://ci.eclipse.org/egit/job/egit.gerrithub, but not sure if it performs a gerrithub action with auth.

I am investigating with Luca what's wrong with the jgit keys he sent me. As soon as they work I will reconfigure the build jobs to fetch from gerrithub instead of git.eclipse.org. That way they should still build all changes since all changes are replicated from git.eclipse.org to gerrithub.

I made some progress on configuring permissions, I can now assign permissions to the github teams I am a member of but not yet to the eclipsefdn-releng and eclipsefdn-security teams. I guess some github permission for the respective OAuth scopes is still missing. As soon as this is fixed I can configure Gerrit permissions.

We found that Luca had sent wrong key for jgit bot. He now sent me the correct key, I validated that it's accepted by eclipse.gerrithub.io and sent it to Sebastien via Bitwarden.

Everything looks fine now, even for jgit

Great, thanks. I will reconfigure the build jobs and prepare permission settings over the weekend

Could you please review permissions for

I temporarily added Luca as a project owner so he can help me in case of issues

What is the impact of these configurations about registered users?

Revert: allows users to revert a change in the WebUI, this creates a new change in review. Requires approval from a committer to be submitted to the respective target branch.
Add Patchset: allows users to upload new patch sets to existing changes of another user. Patch sets are review iterations of a commit produced by commit --amending a commit which is in review and is used to improve a given commit until it is approved by a committer. Can be used to collaborate on the same change.
Push and Push Merge on refs/for/refs/* allows users to push commits and merge commits for review. Requires approval from a committer to be submitted to the respective target branch. Merge commits are needed e.g. to merge fixes from a maintenance branch to the master branch.
Label Code-Review controls who can vote up to which level. A change can be submitted to its target branch if it has at least one +2 vote (approval) and no -2 vote (veto) on the Code-Review label and at least one +1 vote (validation succeeded) and no -1 vote (validation failed) on the Verified label. This means contributors (all registered users) can give their opinion (-1 .. +1) and committers can take decisions (-2 veto, -1 needs improvement, +1 looks good but someone else should have another look, +2 approved)

Thanks for all these explanations. LGTM.

@fgurr Do you have any comment on this?

LGTM

Thanks all. We are almost there ;-) Though Luca found an issue with refreshing the group cache in GerritHub which is used to cache members of GitHub groups. His team is working on a fix and we'd like to await the fix to be finished and deployed before we switch over from git.eclipse.org to eclipse.gerrithub.io.

This is a good news! I'll push the changes made to egit/jgit jenkins instance to jiro project.

As I casually observe, this is turning into a lot of work.

removed due date October 23, 2023

For me it wasn't too much work but it took a while since I am neither an admin of GerritHub nor of the involved GitHub organisations so I had a lot of questions to Luca, Sébastien and Thomas which took time to clarify. Thanks for your patience, I owe you some drinks :-)

My pleasure, I am glad we rescued tens of years of review history of the JGit project! As maintainer of the Gerrit project, this is a win. Thanks everyone for your fruitful cooperation in getting this migration finalised.

Luca.

We are a team! Great work from everybody involved and happy to have it migrated to GitHub.

JIRO PR related:

I pushed PRs with branch protection rules to ensure only the replication bot user can push to the mirrored repos on github.com:

JGit branch protection: https://github.com/eclipse-jgit/.eclipsefdn/pull/3
EGit branch protection: https://github.com/eclipse-egit/.eclipsefdn/pull/3

I added documentation for contributors and committers explaining how to get access and use eclipse.gerrithub.io in the contributor guide: https://wiki.eclipse.org/EGit/Contributor_Guide#Using_Gerrit

Migration of JGit and EGit to GerritHub/GitHub

Designs

Child items ...

Activity

Migration of JGit and EGit to GerritHub/GitHub

Blocks

Relates to

Activity