Community
Participate
Working Groups
Right now a little over half of our project repositories are not 'controlled' by Gerrit, but a mix of CI-users and actual PLs/Teams. This limits the communities ability to contribute and makes certain operations more error prone as exceptions have to be handled manually. I'm targeting June 4, 2018 as the day to fix this by giving it all to Gerrit. Server side the fix will consist of: 1) Adding all CI users to the relevant project teams 2) Creating permissions for all affected repos 3) Changing the actual permissions 4) Gerrit cache flushes 5) Set the permissions projects as parents to the impacted repos The only user side change that should be needed is the update of the remote URLs in .git/config . Users may also want to add ssh keys to Gerrit if they have not already done so. Any concerns? -M.
What about those projects hosted at GitHub?
(In reply to Alexander Nyßen from comment #1) > What about those projects hosted at GitHub? Good question. This change only affects project repositories currently hosted at Eclipse.org. Project repositories at Github will be left as is. -M.
How smooth do you expect this to be? Do users and build systems have to change their repository connections? I ask because we (+0 projects) have Photon RC3 from June 4 to June 8 and on Monday we build our candidate build.
In Oomph's org.eclipse.projects.setup we have two variables like this: <?xml version="1.0" encoding="UTF-8"?> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"> <setup:VariableTask name="eclipse.gerrit.remoteURIs" label="Eclipse Gerrit Repository"> <choice value="https://git.eclipse.org/r/@{remoteURI}" label="HTTPS (read-only, anonymous, Gerrit)"/> <choice value="ssh://${git.user.id|username}@git.eclipse.org:29418/@{remoteURI}" label="SSH (read-write, Gerrit)"> <annotation source="http://www.eclipse.org/oomph/setup/MatchChoice"/> </choice> <choice value="https://${git.user.id|username}@git.eclipse.org/r/@{remoteURI}" label="HTTPS (read-write, Gerrit)"> <annotation source="http://www.eclipse.org/oomph/setup/MatchChoice"/> </choice> <description>Choose from the available remote Gerrit URIs</description> </setup:VariableTask> <setup:VariableTask name="eclipse.git.remoteURIs" label="Eclipse Git Repository"> <choice value="http://git.eclipse.org/gitroot/@{remoteURI}.git" label="HTTP (read-only, anonymous, direct)"/> <choice value="ssh://${git.user.id|username}@git.eclipse.org/gitroot/@{remoteURI}.git" label="SSH (read-write, direct)"> <annotation source="http://www.eclipse.org/oomph/setup/MatchChoice"/> </choice> <choice value="git://git.eclipse.org/gitroot/@{remoteURI}" label="Git (read-only, anonymous, direct)"/> <description>Choose from the available Git URIs</description> </setup:VariableTask> </xmi:XMI> Given a "remoteURI" value, e.g., jdt/eclipse.jdt.core, these provide choices of the different URIs forms that can be used to access the clone, e.g., these choices jdt/eclipse.jdt.core where ${git.user.id|username} is replaced by the user ID, e.g., emerks: https://git.eclipse.org/r/jdt/eclipse.jdt.core ssh://${git.user.id|username}@git.eclipse.org:29418/jdt/eclipse.jdt.core https://${git.user.id|username}@git.eclipse.org/r/jdt/eclipse.jdt.core http://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git ssh://${git.user.id|username}@git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core Are you saying that the latter three URIs will simply stop working as part of the migration? I.e., are Git repos that are already Gerrit-enabled affected because the URIs that can be used to access the repo will be reduced from 6 forms to 3 forms? I think that's what Dani is asking as well...
I am not sure that I understand how that affects me and the Eclipse Riena project. We have currently no Gerrit and no CI Server at eclipse. Can I still push to the Git Repo directly and the Gerrit URL is an option or is it mandatory for all commits to go through Gerrit ? How does Gerrit decide whether a commit is good if there is no build at Eclipse to verify it ? Would that mean that all commits that I push as a committer have to be signed off at the Gerrit webpage ?
(In reply to Christian Campo from comment #5) > Can I still push to the Git Repo directly and the Gerrit URL is an option or > is it mandatory for all commits to go through Gerrit ? By default, committers can push directly to their Git repo and bypass Gerrit reviews. Maybe you'll need to change your push URL though. I hope that the typical non-Gerrit URL could still be used in a read-only mode. @Webmaster: would it? > How does Gerrit decide whether a commit is good if there is no build at > Eclipse to verify it ? Gerrit decides of nothing, it's mostly a tool for committers to review incoming patches. It doesn't merge automatically and so on. The test build -when configured by project team- only gives hints by annotating and commenting the review. It's still up to committers to decide whether to merge or not.
(In reply to Christian Campo from comment #5) I'll answer the parts I understand... But I see while writing this that Mickael answered as well, and I think our answers match. :-P > I am not sure that I understand how that affects me and the Eclipse Riena > project. We have currently no Gerrit and no CI Server at eclipse. > > Can I still push to the Git Repo directly and the Gerrit URL is an option or > is it mandatory for all commits to go through Gerrit ? > As far as I understand, when I migrated to include Gerrit for EMF and XSD, it did not disable any other of the options (URI forms of access), but I believe we asked to support direct commits that bypass Gerrit, which is mostly what I do with EMF, XSD, and Oomph. I believe it was also possible to forbid direct commits that bypass Gerrit. So it's a good question, what will be the default assumption during the migration? > How does Gerrit decide whether a commit is good if there is no build at > Eclipse to verify it ? > Gerrit itself doesn't decide that. There can be an associated CI build that's automatically kicked off and that automatically adds itself as an approver, but if such a CI build job not enabled, only a manual review by a committer of the project is needed to merge the change into master. You can manually remove reviewers as well. > Would that mean that all commits that I push as a committer have to be > signed off at the Gerrit webpage ? I hope not! That was not required in the past, even with Gerrit enabled and I hope that's not required in the future either!!
Thanks Mickael and Ed for the explanation. So if I as a committer decide to NOT use Gerrit, wouldnt that mean that I use the same push URL or why is it necessary to change that ? Gerrit is then just an option for someone to push code too right ? Ny personal opinion however is that we have long tried to find people to contribute to Riena and failed really I admit. Not really convinced that this will change with a Gerrit instance and maybe there are other projects that are very simular. So I think the first 50% that are already using Gerrit will also be those that benefit most from Gerrit. The second 50% will be benefit a lot lesss since they dont get contributions for whatever reasons anyway....
Gerrit has significant benefits for casual contributors. Checking out and building a project is moderately easy. Testing a project is much harder and completely hidden by the Gerrit builds. A user is free to make whatever tweaks they feel like and is able to discover how much is broken without involving the project team to review every half-baked attempt.
(In reply to Christian Campo from comment #8) > Thanks Mickael and Ed for the explanation. > > So if I as a committer decide to NOT use Gerrit, wouldnt that mean that I > use the same push URL or why is it necessary to change that ? > Yes, that depends the answer to the question of whether all these will continue to work: https://git.eclipse.org/r/jdt/eclipse.jdt.core ssh://${git.user.id|username}@git.eclipse.org:29418/jdt/eclipse.jdt.core https://${git.user.id|username}@git.eclipse.org/r/jdt/eclipse.jdt.core http://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git ssh://${git.user.id|username}@git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core or whether these three will stop working after the migration: http://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git ssh://${git.user.id|username}@git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core If these three don't work, the URI needs to be changed to the corresponding Gerrit version. > Gerrit is then just an option for someone to push code too right ? > Yes, that's one of the primary goals. It allows contributors to commit changes to Gerrit, where you can review and approve/reject them. > Ny personal opinion however is that we have long tried to find people to > contribute to Riena and failed really I admit. Not really convinced that > this will change with a Gerrit instance and maybe there are other projects > that are very simular. > There is no Oomph setup for Riena, and I see nothing on https://www.eclipse.org/riena/ that would help me create a workspace containing the Riena code. Any contributor would be pretty much in the dark, not even knowing the location of your clone. So there certainly isn't an open invitation apparent to me... > So I think the first 50% that are already using Gerrit will also be those > that benefit most from Gerrit. The second 50% will be benefit a lot lesss > since they dont get contributions for whatever reasons anyway.... In the end, I don't think this migration will hurt anyone. It's mostly a question of whether a different URI can be used, or perhaps must be used...
Given Matt's requirement to clean up permissions of the git repos, everything would have to go through the gerrit URI. You can direct commit to a branch using that URI (the one with port 29418). Gerrit only creates reviews for things pushed to refs/for/<branch>. Matt should be able to confirm that ;).
(In reply to Dani Megert from comment #3) > How smooth do you expect this to be? Do users and build systems have to > change their repository connections? I expect it to be more or less hassle free, but yes some repo URLs will probably need to be updated. > I ask because we (+0 projects) have Photon RC3 from June 4 to June 8 and on > Monday we build our candidate build. Ok, I'm willing to move it a week or so before/after. Which would be preferable? (In reply to Ed Merks from comment #10) > https://git.eclipse.org/r/jdt/eclipse.jdt.core > ssh://${git.user.id|username}@git.eclipse.org:29418/jdt/eclipse.jdt.core > https://${git.user.id|username}@git.eclipse.org/r/jdt/eclipse.jdt.core These are all Gerrit based URLs so they should be just fine. > http://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git > ssh://${git.user.id|username}@git.eclipse.org/gitroot/jdt/eclipse.jdt.core. > git > git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core These links should continue to function for checkout at least, but you won't be able to push. The servers that provide access via these URLs are due for an upgrade, and once everything is in Gerrit there will be less/no need to run a separate git service. However that's a few months off right now. > Gerrit is then just an option for someone to push code too right ? Yes and no. With this change Gerrit will become the git server for all repos. However as others have noted you won't be forced to use the code review functionality if you don't want to. That's why the only expected change is in the URLs for push ie: ssh://${git.user.id|username}@git.eclipse.org/gitroot/jdt/eclipse.jdt.core will become ssh://${git.user.id|username}@git.eclipse.org:29418/jdt/eclipse.jdt.core Committers not currently using Gerrit will probably want to upload their ssh keys to Gerrit to make things almost seamless. While Gerrit doesn't 'guaranty' increased community input, it should make it easier for people that want to contribute. (In reply to Doug Schaefer from comment #11) > Matt should be able to confirm that ;). Correct, using the reviews feature requires the push be to refs/for/<branch>. Without that Gerrit will just act like a normal Git server. -M.
I assume Eclipse top-level project repos aren't moved yet. Could we move one repo to test the impact and create a migration guide for developers before we do a mass change?
(In reply to Dani Megert from comment #13) > I assume Eclipse top-level project repos aren't moved yet. Could we move one > repo to test the impact and create a migration guide for developers before > we do a mass change? Sure thing. Pick a repo and a time next week(April 23-27) that works for you. -M.
(In reply to Eclipse Webmaster from comment #14) > (In reply to Dani Megert from comment #13) > > I assume Eclipse top-level project repos aren't moved yet. Could we move one > > repo to test the impact and create a migration guide for developers before > > we do a mass change? > > Sure thing. Pick a repo and a time next week(April 23-27) that works for > you. > > -M. Let's try with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/ This has lots of committers and Gerrits. A good time would be Wednesday, April 25 if possible (Mikaël?) in the CEST morning. Otherwise early morning EDT.
I may be wrong, but I believe that since all Eclipse Platform repos do already allow incoming patches through Gerrit, they're already controlled by Gerrit, aren't they?
To make this change less disruptive, I'd propose: - setup gerrit to listen to both ports 22 and 29418 (see https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#sshd.listenAddress)? - redirect http://git.eclipse.org/gitroot/<X> to https://git.eclipse.org/r/<X> and ssh://git.eclipse.org/gitroot/<X> to ssh://git.eclipse.org/<X>? This way, we would only break git:// users, who can't push anyway IIRC. Also, I'm thinking about committers who don't use Gerrit: they will be force to log into gerrit to add their ssh key or generate https password. What about adding ssh public key and https password management to account.eclipse.org? (probably using gerrit REST API)
(In reply to Mikaël Barbero from comment #17) > To make this change less disruptive, I'd propose: My goal is to actually show how disruptive the change will be. And then you can compile instructions. Aren't there ways to hide those URL changes for committers?
(In reply to Dani Megert from comment #18) > (In reply to Mikaël Barbero from comment #17) > > To make this change less disruptive, I'd propose: > > My goal is to actually show how disruptive the change will be. And then you > can compile instructions. > > Aren't there ways to hide those URL changes for committers? That's exactly my proposal ;) Not change except for people using git://
(In reply to Mikaël Barbero from comment #19) > (In reply to Dani Megert from comment #18) > > (In reply to Mikaël Barbero from comment #17) > > > To make this change less disruptive, I'd propose: > > > > My goal is to actually show how disruptive the change will be. And then you > > can compile instructions. > > > > Aren't there ways to hide those URL changes for committers? > > That's exactly my proposal ;) Ah, OK. That was for the server side. > Not change except for people using git:// That would be perfect.
(In reply to Dani Megert from comment #15) > Let's try with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/ > > A good time would be Wednesday, April 25 if possible (Mikaël?) in the CEST > morning. Otherwise early morning EDT. Ok I've added a calendar reminder for this. (In reply to Mickael Istria from comment #16) > they're already controlled by Gerrit, aren't they? Not by direct ownership. The platform repos use ACLs to give gerrit access. -M.
(In reply to Dani Megert from comment #15) > A good time would be Wednesday, April 25 if possible (Mikaël?) in the CEST > morning. Otherwise early morning EDT. This has been done, so don't forget to update your URLs(if you haven't already). Let us know how it goes. -M.
(In reply to Eclipse Webmaster from comment #22) > (In reply to Dani Megert from comment #15) > > > A good time would be Wednesday, April 25 if possible (Mikaël?) in the CEST > > morning. Otherwise early morning EDT. > > This has been done, so don't forget to update your URLs(if you haven't > already). Did you already create a wiki page with the migration guide that describes exactly what to change? See comment 13.
(In reply to Eclipse Webmaster from comment #22) > (In reply to Dani Megert from comment #15) > > > A good time would be Wednesday, April 25 if possible (Mikaël?) in the CEST > > morning. Otherwise early morning EDT. > > This has been done, so don't forget to update your URLs(if you haven't > already). Not sure what I have to do. I have [remote "origin"] url = ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git Pulling worked fine, but (direct) pushing gives: Can't connect to any repository: ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git (ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git: error occurred during unpacking on the remote end: unpack-objects abnormal exit) So, a wiki page that exactly describes how to change the direct push URL and the one for Gerrit would be really needed. For Gerrit I currently have: [remote "gerrit"] url = ssh://dmegert@git.eclipse.org:29418/platform/eclipse.platform.ui.git fetch = +refs/heads/*:refs/remotes/origin/* fetch = refs/notes/*:refs/notes/* push = HEAD:refs/for/master and that worked.
I still haven't found a way to push directly, so at this point -2 from me to make this change. Please provide a migration guide that explains the steps to keep existing workflows!
(In reply to Dani Megert from comment #25) > I still haven't found a way to push directly, so at this point -2 from me to > make this change. > > Please provide a migration guide that explains the steps to keep existing > workflows! If you're using egit, just make sure you push branch from the git repositories view. That pushes directly. It's more awkward than the Git Staging view's Commit and Push button, but you it should be a low runner use case anyway.
Sorry, going through these in the wrong order. You can only push to the gerrit URL (port 29418). You have to push directly to the branch you want (not the refs/for). git push gerrit master should do the trick. Though I use egit all the time so I'm can be totally positive that's the right arguments. (In reply to Dani Megert from comment #24) > Not sure what I have to do. > > I have > > [remote "origin"] > url = ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git > > Pulling worked fine, but (direct) pushing gives: > > Can't connect to any repository: > ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git > (ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git: > error occurred during unpacking on the remote end: unpack-objects abnormal > exit) > > So, a wiki page that exactly describes how to change the direct push URL and > the one for Gerrit would be really needed. > > > For Gerrit I currently have: > [remote "gerrit"] > url = ssh://dmegert@git.eclipse.org:29418/platform/eclipse.platform.ui.git > fetch = +refs/heads/*:refs/remotes/origin/* > fetch = refs/notes/*:refs/notes/* > push = HEAD:refs/for/master > > and that worked.
(In reply to Dani Megert from comment #24) > Can't connect to any repository: > ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git > (ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git: > error occurred during unpacking on the remote end: unpack-objects abnormal > exit) The error is 'expected', since gerrit now owns the repo your user has no permissions to update the filesystem. If we deploy Mikaels suggestion from comment #17 to have Gerrit answer on port 22 then I would presume these URLs might just work. However at this time that would cause all the projects that are impacted by this change to be unable to commit, which sort of defeats the purpose of trying it out on a limited number of repos. > So, a wiki page that exactly describes how to change the direct push URL and > the one for Gerrit would be really needed. Rather than a wiki page which would be quickly abandoned I was planning on collecting the experiences from this bug and putting it all into an email that we would send out. Comment #12 covered what I thought was going to be the 'standard' change required for URLs, although Dougs updates perhaps capture it better. -M.
(In reply to Doug Schaefer from comment #27) > Sorry, going through these in the wrong order. > > You can only push to the gerrit URL (port 29418). You have to push directly > to the branch you want (not the refs/for). > > git push gerrit master if origin is your git repo's remote referring to the ssh or https gerrit URL do git push origin <local branch>:<upstream branch> e.g. git push origin HEAD:master to push current branch to master > > should do the trick. Though I use egit all the time so I'm can be totally > positive that's the right arguments. > > (In reply to Dani Megert from comment #24) > > Not sure what I have to do. > > > > I have > > > > [remote "origin"] > > url = ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git > > > > Pulling worked fine, but (direct) pushing gives: > > > > Can't connect to any repository: > > ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git > > (ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git: > > error occurred during unpacking on the remote end: unpack-objects abnormal > > exit) > > use port 29418 in order to push to Gerrit over ssh > > So, a wiki page that exactly describes how to change the direct push URL and > > the one for Gerrit would be really needed. > > > > > > For Gerrit I currently have: > > [remote "gerrit"] > > url = ssh://dmegert@git.eclipse.org:29418/platform/eclipse.platform.ui.git > > fetch = +refs/heads/*:refs/remotes/origin/* > > fetch = refs/notes/*:refs/notes/* > > push = HEAD:refs/for/master > > > > and that worked.
In order to make direct push work I had to make two changes (as outlined in comment 12): 1. Add the port for Gerrit (29418) 2. Remove /gitroot [remote "origin"] url = ssh://dmegert@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git ==> url = ssh://dmegert@git.eclipse.org:29418/platform/eclipse.platform.ui.git In addition, Those who used to use their ID (dmegert in my case) as author and committer have to change it to their e-mail address. NOTE: The URLs have to be adjusted on http://git.eclipse.org/c/platform/eclipse.platform.ui.git/ (i.e. for each migrated project).
(In reply to Dani Megert from comment #30) > In addition, Those who used to use their ID (dmegert in my case) as author > and committer have to change it to their e-mail address. Good to know, thanks! -M.
(In reply to Eclipse Webmaster from comment #12) > > I ask because we (+0 projects) have Photon RC3 from June 4 to June 8 and on > > Monday we build our candidate build. > > Ok, I'm willing to move it a week or so before/after. Which would be > preferable? I'm no longer that concerned after we moved Platform UI. For me the earlier the better.
I found One problem after we moved to Gerrit. We have this in the platform.ui config in the repo used for the build [remote "origin"] url = file:///gitroot/platform/eclipse.platform.ui fetch = +refs/heads/*:refs/remotes/origin/* After moving to gerrit the tags are not getting pushed anymore. Can you please let us know how we can get this fixed?
In order to fix that, I would need to know from which JIPP do you push tags to platform/eclipse.platform.ui? Is it Releng?
(In reply to Mikaël Barbero from comment #34) > In order to fix that, I would need to know from which JIPP do you push tags > to platform/eclipse.platform.ui? Is it Releng? yes. We use releng JIPP for pushing tags here is the error message 20:06:36 Entering 'eclipse.platform.ui' 20:06:36 Pushing to file:///gitroot/platform/eclipse.platform.ui 20:06:48 fatal: Unable to create '/home/data/git/platform/eclipse.platform.ui.git/refs/tags/I20180429-2000.lock': Permission denied 20:06:48 fatal: The remote end hung up unexpectedly 20:06:48 fatal: The remote end hung up unexpectedly
You JIPP user can now push via ssh. Please update your git URIs to ssh://genie.releng@git.eclipse.org:29418/platform/eclipse.platform.ui.git
(In reply to Mikaël Barbero from comment #36) > You JIPP user can now push via ssh. Please update your git URIs to > > ssh://genie.releng@git.eclipse.org:29418/platform/eclipse.platform.ui.git Sorry it failed during clone 06:30:24 git clone --recursive -b master ssh://genie.releng@git.eclipse.org:29418/platform/eclipse.platform.releng.aggregator.git 06:30:24 Cloning into 'eclipse.platform.releng.aggregator'... 06:30:25 Host key verification failed. 06:30:25 fatal: Could not read from remote repository. 06:30:25 06:30:25 Please make sure you have the correct access rights 06:30:25 and the repository exists. you can use https://hudson.eclipse.org/releng/view/Builds/job/I-build-Photon to test
git.eclipse.org was not in the .ssh/known_hosts file. I have added it and restarted a build. Seems to be better now.
(In reply to Mikaël Barbero from comment #38) > git.eclipse.org was not in the .ssh/known_hosts file. I have added it and > restarted a build. Seems to be better now. Clone is working fine. lets wait and see how the push works.
(In reply to Sravan Kumar Lakkimsetti from comment #39) > (In reply to Mikaël Barbero from comment #38) > > git.eclipse.org was not in the .ssh/known_hosts file. I have added it and > > restarted a build. Seems to be better now. > > Clone is working fine. lets wait and see how the push works. Tagging also working now. I will update this bug if I encounter anymore problems
(In reply to Dani Megert from comment #32) > I'm no longer that concerned after we moved Platform UI. For me the earlier > the better. Since it looks like we've got things sorted, if PLs would like their project to move ahead of the current target date please send Webmaster an email, and we can find a date that works. -M.
*** Bug 452549 has been marked as a duplicate of this bug. ***
Hi, We (openj9-website) might be a special case. Our main repo is on Github and we mirror it to Eclipse when changes are merged at Github. Today we updated our build URLs to use the new ssh with user and port. https://github.com/eclipse/openj9-website/pull/96 - ECLIPSE_REPO = '/gitroot/www.eclipse.org/openj9.git' + ECLIPSE_REPO = 'ssh://genie.openj9@git.eclipse.org:29418/www.eclipse.org/openj9.git' Unfortunately our mirror jobs gets a permissions error when trying to push. I assume since the Pull Request merge email belongs to github we are seeing the error. Not sure if we can just add that email to our bot account? It was a bit of a surprise because we have a Pull Request build that tested the new url and it worked there. ######################### + git push upstream master remote: remote: Processing changes: refs: 1 remote: Processing changes: refs: 1, done remote: remote: ERROR: In commit 66926757ec0ebb95f6ddcb7b144f7623dcf652d5 remote: ERROR: committer email address noreply@github.com remote: ERROR: does not match your user account. remote: ERROR: remote: ERROR: The following addresses are currently registered: remote: ERROR: openj9-bot@eclipse.org remote: ERROR: remote: ERROR: To register an email address, please visit: remote: ERROR: https://git.eclipse.org/r/#/settings/contact remote: remote: To ssh://git.eclipse.org:29418/www.eclipse.org/openj9.git ! [remote rejected] master -> master (invalid committer) error: failed to push some refs to 'ssh://genie.openj9@git.eclipse.org:29418/www.eclipse.org/openj9.git' #########################
Hi Mikael Please see Adam's comment 43, which might have got buried in this long chain. We have a release imminent and I don't think we are able to update our project website until we've found a way around our issue mirroring from GitHub to Eclipse GIT. Please can you help? Thanks Sue
(In reply to Sue Chaplain from comment #44) > Hi Mikael > > Please see Adam's comment 43, which might have got buried in this long > chain. We have a release imminent and I don't think we are able to update > our project website until we've found a way around our issue mirroring from > GitHub to Eclipse GIT. > > Please can you help? > Thanks > Sue Replication fails since the replication user identity doesn't match the committer identity of the commits being replicated. The Gerrit application identifies the user via authentication, git identifies users by their email address. Gerrit by default requires that the Committer email address in a commit being pushed matches a registered email address of the authenticated Gerrit user. This prevents that anyone can forge the committer identity. You can fix this by asking a Gerrit admin to grant the ForgeCommitter privilege [2] on "refs/*" to the user used for replication in the permission settings of your project [3]. [1] https://git.eclipse.org/r/#/admin/projects/All-Projects,access [2] https://git.eclipse.org/r/Documentation/access-control.html#category_forge_committer [3] https://git.eclipse.org/r/#/admin/projects/openj9/openj9,access
Thank you Matthias. I've opened another bugzilla to handle: https://bugs.eclipse.org/bugs/show_bug.cgi?id=535677
Hello, i have a question regarding the move and mwe mwe was at git://git.eclipse.org/gitroot/emf/org.eclipse.mwe.git and mirrored to https://github.com/eclipse/mwe what is the new uri for that repo. https://git.eclipse.org/r/www.eclipse.org/emf/mwe is hopelessly outdated compared to above was mwe already moved? if yes why the difference if no when is it planned?
(In reply to Christian Dietrich from comment #47) > Hello, > > i have a question regarding the move and mwe > > mwe was at > git://git.eclipse.org/gitroot/emf/org.eclipse.mwe.git > and mirrored to > https://github.com/eclipse/mwe > > what is the new uri for that repo. > https://git.eclipse.org/r/www.eclipse.org/emf/mwe is hopelessly outdated > compared to above org.eclipse.mwe.git != www.eclipse.org/emf/mwe. The latter was/is most likely the EMF MWE website and not the source code repository. > was mwe already moved? > if yes why the difference > if no when is it planned? The MWE source git repo has not been moved to Gerrit yet. @Webmaster: When is this planned? Are we holding off until after Photon is released?
(In reply to Frederic Gurr from comment #48) > > git://git.eclipse.org/gitroot/emf/org.eclipse.mwe.git > > and mirrored to > > https://github.com/eclipse/mwe Just as a general comment, we have found the Github mirrors to be 'not great' and so have been removing them over time. > org.eclipse.mwe.git != www.eclipse.org/emf/mwe. The latter was/is most > likely the EMF MWE website and not the source code repository. Yup. > The MWE source git repo has not been moved to Gerrit yet. Correct. > @Webmaster: When is this planned? Are we holding off until after Photon is > released? It's currently ongoing. I'm avoiding projects involved in Photon, and moving a handful at a time. I have been posting notices to the -dev list for projects that have been moved with details about the move. -M.
so if we want to move to github with mwe to align with the xtext development process anyway we should open the bugzilla for that right now so that we do not need to to the intermediary move to gerrit
(In reply to Christian Dietrich from comment #50) > so if we want to move to github with mwe to align with the xtext development > process anyway we should open the bugzilla for that right now so that we do > not need to to the intermediary move to gerrit Yup. -M.
I'm going to close this as resolved as all repos are now controlled by Gerrit. -M.
