Replication to GitHub and Write access to users

[Charly]

Hi,

My organization has been using Gerrit for a few years now, and we're very happy with it!

We recently decided to publish our repositories on GitHub, so we configured Gerrit's replication plugin to automatically push submitted commits to GitHub. This part works like a charm. To be sure that our users wouldn't push to GitHub by mistake and mess up the replication, we've also limited their access by granting them the GitHub "Read" permission only.

Now, we would like our users to be able to update and/or close GitHub Issues that are being opened on these repositories. However, from what I understand of GitHub's documentation, this requires that a user is granted the "Write" permission. We would like to allow all our users to update and/or close GitHub Issues, but doing so we'd also grant them permissions to push to GitHub repositories, at the risk of breaking the replication from Gerrit.

I've quickly scanned this group's topics and couldn't find a similar story. I also looked into Gerrit's GitHub plugin, but it doesn't appear to handle GitHub's Issues (at least not the current version – I'm unsure what the its-github plugin is about).

Does anybody have experience with this kind of setup? What would be your suggestion(s)?

Many thanks in advance!

Charly

[Saša Živkov]

On Mon, Jun 13, 2016 at 12:20 AM, Charly <jcd....@gmail.com> wrote:

Hi,

My organization has been using Gerrit for a few years now, and we're very happy with it!

We recently decided to publish our repositories on GitHub, so we configured Gerrit's replication plugin to automatically push submitted commits to GitHub. This part works like a charm. To be sure that our users wouldn't push to GitHub by mistake and mess up the replication, we've also limited their access by granting them the GitHub "Read" permission only.

Now, we would like our users to be able to update and/or close GitHub Issues that are being opened on these repositories. However, from what I understand of GitHub's documentation, this requires that a user is granted the "Write" permission. We would like to allow all our users to update and/or close GitHub Issues, but doing so we'd also grant them permissions to push to GitHub repositories, at the risk of breaking the replication from Gerrit.

Have you asked at a GitHub discussion group?

This looks like a GitHub access rights question.

 

I've quickly scanned this group's topics and couldn't find a similar story. I also looked into Gerrit's GitHub plugin, but it doesn't appear to handle GitHub's Issues (at least not the current version – I'm unsure what the its-github plugin is about).

Does anybody have experience with this kind of setup? What would be your suggestion(s)?

Many thanks in advance!

Charly

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luca Milanesio]

From our experience with GerritHub.io, typically GitHub users want to keep the ability to push to GitHub as well, even if the repos are configured for replication from Gerrit.

This may create some problem with the replication going out-of-sync :-(

As long as they know what they are doing (I doubt it happens very often), it should not be a problem.

P.S. Should you want to go this (dangerous) way, fasten your seat belts and disable force-push from Gerrit replication config. Bear in mind as well that you wouldn't be able to replicate force pushes and branch deletion.

Good luck :-)

Luca.

[Charly]

Now, we would like our users to be able to update and/or close GitHub Issues that are being opened on these repositories. However, from what I understand of GitHub's documentation, this requires that a user is granted the "Write" permission. We would like to allow all our users to update and/or close GitHub Issues, but doing so we'd also grant them permissions to push to GitHub repositories, at the risk of breaking the replication from Gerrit.

Have you asked at a GitHub discussion group?

This looks like a GitHub access rights question. 

Thanks for your suggestion. This is something I planned on doing but wanted to gather Gerrit's experts opinion first, in case I missed something obvious.

I'm afraid they won't really consider my questions tho since it is really not an issue with GitHub's permission system from GitHub's point of view. (this only becomes an issue when you use GitHub's repository as "slaves" rather than "masters").

I'll ask nonetheless and report here if I get any useful reply.

Charly

[Charly]

From our experience with GerritHub.io, typically GitHub users want to keep the ability to push to GitHub as well, even if the repos are configured for replication from Gerrit.

This may create some problem with the replication going out-of-sync :-(

As long as they know what they are doing (I doubt it happens very often), it should not be a problem.

P.S. Should you want to go this (dangerous) way, fasten your seat belts and disable force-push from Gerrit replication config. Bear in mind as well that you wouldn't be able to replicate force pushes and branch deletion.

Good luck :-)

Hi Luca,

Thanks for your reply!

Unfortunately, I can't say that all our users are 100% comfortable with Git in general, and I'm afraid they could easily make a mistake say for example when trying to test a pull request: they would typically add the GitHub repository as a new remote to fetch the PR and test it locally (eg. following some written procedure), and then one day push to all remotes or to the wrong remote by mistake (this can happen for example if they get stuck with some error and instead of trying to understand it simply copy/paste a command from Stack Overflow or such).

As I understand it, there's no 100% bulletproof solution and the best way to prevent this scenario is through user training and close monitoring of the synchronization process.

I'll keep poking around and report on this mailing list should I find any better solution :-)

Best,

Charly