Happy New Year ... new year, new life for the GitHub plugin

[lucamilanesio]

• Happy New Year to the Gerrit mailing list ... at least for those in the GMT+N time-zone :-)
  

We have a saying from Italy: "New Year = New Life". I would like to apply this to the GitHub plugin and I need feedback from the community about my ideas.

Fact: the GitHub plugin is getting too big  and too old!

• Does too many things (OAuth authentication, Profile migration, Replication wizard, Pull request import, Group Backends integration, WebHooks)
• Overlaps with Gerrit native features (see the OAuth mentioned before)
• It has too many old-fashioned frameworks (aka Velocity templates)
• Relies on an old-fashioned HTTP-based authentication 
• ... and worst of all, is built with Maven :-)

Instead of keeping pushing new features to a beefy code-base, I thought about "why not redesigning the whole thing and start smaller?"

Additionally people may be interested only in some of the GitHub plugin features (e.g. Replication wizard) and not others: breaking and simplifying the whole thing will have interesting reuse by more people.

My idea is to break the plugin into:

1. GitHub-OAuth provider [gerrit-oauth-provider] (not a new one, but reusing the DavidO's plugin)
2. GitHub-Profile importer [github-profile] - responsible for migrating and synchronising your GitHub profile with Gerrit
3. Replication wizard [github-replication] - for importing and configuring GitHub repos into Gerrit replication plugin with the current "one-click" experience
4. Pull request importer [github-pullrequest] - for importing GitHub pull requests as Gerrit changes
5. GitHub WebHooks [github-webhooks] - Gerrit listing to GitHub WebHooks and automating Gerrit tasks, such as pull request import
6. GitHub-Groups backend [github-groups] - for plugging GitHub Organisations and Teams as Gerrit Groups

Additionally new plugins will "join the party" by providing even more interesting and useful features:

• GitHub issues associations [its-github] - for implementing the GitHub issues as one of the ITS-* providers for associating and managing issues automation with Gerrit
• Push-pull replication [push-pull-replication] - for implementing a push+pull replication logic for GitHub repositories
• Replications tatus [replication-status] - for recording and rendering the repository's replication status and associated error logs on the Gerrit GUI

--- * ---

Let's go now through the plus and minuses of the new approach.

PLUS

- Simpler for new contributor to add ideas and approach a simpler and leaner code-base

- Allows reuse of individual plugins in other domains (e.g. GitHub pull request importer even using a non-GitHub authentication style)

- Based on new frameworks and more modern code base

- Easier to maintain and add new features

MINUS

- Gerrit does not have a inter-plugin dependency system: it will be difficult for people to understand how to put things together

- Gerrit init phase would become a bit messy, as every individual plugin will have its own init step

- Configuration will be split into multiple sections and logic, again risk of making a bit of a mess

- Migration: how to allow existing GitHub plugin users to migrate to the "new thing"?

---

New Year = New Ideas = New Feedback is more than welcome :-)

Luca.

[Shawn Pearce]

On Thu, Dec 31, 2015 at 5:11 PM, lucamilanesio <luca.mi...@gmail.com> wrote:

My idea is to break the plugin into:

This is a great idea.

MINUS

- Gerrit does not have a inter-plugin dependency system: it will be difficult for people to understand how to put things together

Yea, sorry. I meant to do this during the last hackathon, but you got monitoring instead.

[Matthew McCormick]

Sounds awesome!

[Marco Massenzio]

Ciao, Luca.

Any progress on this one?

I'm trying to use Gerrit with our internal GitHub Enterprise and I'm kinda lost trying to figure out a way how to avoid the two hating each other.

I've found some blogs online, the plugin itself is very scarce on documentation / how-to (but maybe I'm looking in the wrong place) and I really do NOT want github auth, as I MUST use LDAP internally (this works on my Gerrit server, so that's ok).

Essentially, I'm looking for some guidance on how to integrate a Gerrit server with our Github main repository.

The way I see it, currently, this is not possible.  Am I right?

Many thanks in advance for any guidance you may provide.

Marco.

PS - mvn is just fine LoL

(but why not just distribute a JAR and be done with it?)

[luca.mi...@gmail.com]

Ciao Marco,

if the only thing you need is to replicate to GHE, you can just use the replication plugin.

This split of GitHub plugin hasn't started yet ... @Gerrit maintainers why don't you start creating the Repos for me? :-)

Luca

Sent from my iPhone

--
--
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.

[Edwin Kempin]

On Fri, Apr 29, 2016 at 8:13 AM, <luca.mi...@gmail.com> wrote:

Ciao Marco,

if the only thing you need is to replicate to GHE, you can just use the replication plugin.

This split of GitHub plugin hasn't started yet ... @Gerrit maintainers why don't you start creating the Repos for me? :-)

Huh, missed that there was a request to create repos.

Which exact repos do you need?

[Luca Milanesio]

Thanks Edwin for the new repos will start with the initial README.md push right now.

See below my feedback.

On 29 Apr 2016, at 07:52, Edwin Kempin <eke...@google.com> wrote:

On Fri, Apr 29, 2016 at 8:31 AM, <luca.mi...@gmail.com> wrote:

Hi Edwin, see below the list with the associated descriptions :-)

1. GitHub-OAuth provider [gerrit-oauth-provider] (not a new one, but reusing the DavidO's plugin)

Ok, but the gerrit-oauth-provider is on GitHub, will it stay there?

@DavidO are you OK to move your code to Gerrit? It would be so much easier for the Gerrit Community to follow "what is going on" in a single place :-)

 

1. GitHub-Profile importer [github-profile] - responsible for migrating and synchronising your GitHub profile with Gerrit

 https://gerrit-review.googlesource.com/#/admin/projects/plugins/github-profile

1. Replication wizard [github-replication] - for importing and configuring GitHub repos into Gerrit replication plugin with the current "one-click" experience

https://gerrit-review.googlesource.com/#/admin/projects/plugins/github-replication

 

1. Pull request importer [github-pullrequest] - for importing GitHub pull requests as Gerrit changes

https://gerrit-review.googlesource.com/#/admin/projects/plugins/github-pullrequest

1. GitHub WebHooks [github-webhooks] - Gerrit listing to GitHub WebHooks and automating Gerrit tasks, such as pull request import

https://gerrit-review.googlesource.com/#/admin/projects/plugins/github-webhooks

1. GitHub-Groups backend [github-groups] - for plugging GitHub Organisations and Teams as Gerrit Groups

https://gerrit-review.googlesource.com/#/admin/projects/plugins/github-groups

 

• GitHub issues associations [its-github] - for implementing the GitHub issues as one of the ITS-* providers for associating and managing issues automation with Gerrit

https://gerrit-review.googlesource.com/#/admin/projects/plugins/its-github

 

• Push-pull replication [push-pull-replication] - for implementing a push+pull replication logic for GitHub repositories

https://gerrit-review.googlesource.com/#/admin/projects/plugins/push-pull-replication

 

• Replications tatus [replication-status] - for recording and rendering the repository's replication status and associated error logs on the Gerrit GUI

https://gerrit-review.googlesource.com/#/admin/projects/plugins/replication-status

 

Sent from my iPhone

[David Ostrovsky]

Am Freitag, 29. April 2016 09:06:32 UTC+2 schrieb lucamilanesio:

Thanks Edwin for the new repos will start with the initial README.md push right now.

See below my feedback.

On 29 Apr 2016, at 07:52, Edwin Kempin <eke...@google.com> wrote:

On Fri, Apr 29, 2016 at 8:31 AM, <luca.mi...@gmail.com> wrote:

Hi Edwin, see below the list with the associated descriptions :-)

1. GitHub-OAuth provider [gerrit-oauth-provider] (not a new one, but reusing the DavidO's plugin)

Ok, but the gerrit-oauth-provider is on GitHub, will it stay there?

@DavidO are you OK to move your code to Gerrit? It would be so much easier for the Gerrit Community to follow "what is going on" in a single place :-)

Yes ;-)

Edwin already created the project for it and I pushed the sources for review: [1].

* [1] https://gerrit-review.googlesource.com/69913

[Edwin Kempin]

Nice! Should I rather create a new project [plugins/github-oauth] for it, so that the name matches with the other github plugin projects?

 

[Luca Milanesio]

Can I request to be one of the approvers :-) ? 

[Luca Milanesio]

Hi Edwin,

I think the current name still makes sense, as other OAuth providers are supported as well (e.g. Google).

Luca.

[David Ostrovsky]

2016-04-29 11:01 GMT+02:00 Luca Milanesio <luca.mi...@gmail.com>:

Can I request to be one of the approvers :-) ? 

Everyone would like to have +2 here... Done. 

[Luca Milanesio]

... because it is the best plugin ever ;-)

Thanks David !

Luca.

[Luca Milanesio]

In order to avoid loosing all the history from the GitHub project ... can we just push the current GitHub repo 'as-is' and from now on take all the new changes as Gerrit Reviews?

Luca.

[David Ostrovsky]

2016-04-29 11:19 GMT+02:00 Luca Milanesio <luca.mi...@gmail.com>:

In order to avoid loosing all the history from the GitHub project ... can we just push the current GitHub repo 'as-is' and from now on take all the new changes as Gerrit Reviews?

Yes, that makes sense. One change is to adjust to the new name of the plugin.

[Luca Milanesio]

Can I press the "PUSH" button? :-)

[David Ostrovsky]

2016-04-29 11:24 GMT+02:00 Luca Milanesio <luca.mi...@gmail.com>:

Can I press the "PUSH" button? :-)

Jepp ;-)

[Luca Milanesio]

DONE :-)

[Marco Massenzio]

On Thu, Apr 28, 2016 at 11:13 PM, <luca.mi...@gmail.com> wrote:

Ciao Marco,

if the only thing you need is to replicate to GHE, you can just use the replication plugin.

​Thanks, Luca.

This is what I found: https://gerrit.googlesource.com/plugins/replication/+doc/master/src/main/resources/Documentation/about.md

There is no indication of how to get/build/install it, however, I got to clone its repo:
$ git clone https://gerrit.googlesource.com/plugins/replication

Then I did this (why, oh, why are you guys using buck? never heard of it, it's not very helpful either) largely guessing what to do, because, again, there is no README that tells me how to build the plugin, and (as one might expect) it didn't work:

$ buck build :gerrit_plugin

OR
$ buck build :maven_jar

the outcome is still the same:

Parse error for build file /Users/mmassenzio/Development/replication/BUCK:   File "/Users/mmassenzio/Development/replication/BUCK", line 1, in <module>
    include_defs('//lib/maven.defs')
  File "/Users/mmassenzio/Development/replication/buck-out/tmp/buck_run.vTZA8o/buck8854395952966146876.py", line 584, in _include_defs
    implicit_includes=implicit_includes)
  File "/Users/mmassenzio/Development/replication/buck-out/tmp/buck_run.vTZA8o/buck8854395952966146876.py", line 687, in _process_include
    implicit_includes=implicit_includes)
  File "/Users/mmassenzio/Development/replication/buck-out/tmp/buck_run.vTZA8o/buck8854395952966146876.py", line 662, in _process
    with open(path, 'r') as f:
IOError: [Errno 2] No such file or directory: '/Users/mmassenzio/Development/replication/lib/maven.defs'

As an aside, the other day I gave up trying to install the download_commands plugin exactly for the same reason: no documentation, no instructions on how to build/distribute it.

As a Gerrit user, is there a simple way to install plugins without incurring the cost of becoming familiar with (a) buck (seriously, guys, Maven or Gradle are just fine :), (b) the Gerrit plugin system and (c) whatever else is necessary to learn?

All I'd really like to do is to use Gerrit as our team's code review tool (which I really really like and I think it's awesome, but am reluctantly coming to the conclusion it's just too much work to setup).

Many thanks in advance for any help anyone could provide.

​

 

[Luca Milanesio]

Hi Marco,

Gerrit Code Review is OpenSource, which does not mean *FREE LUNCH*: you need to invest time in studying the project and reading through the huge set of documentation provided.

On 29 Apr 2016, at 21:19, Marco Massenzio <m.mas...@gmail.com> wrote:

On Thu, Apr 28, 2016 at 11:13 PM, <luca.mi...@gmail.com> wrote:

Ciao Marco,

if the only thing you need is to replicate to GHE, you can just use the replication plugin.

​Thanks, Luca.

This is what I found: https://gerrit.googlesource.com/plugins/replication/+doc/master/src/main/resources/Documentation/about.md

There is no indication of how to get/build/install it,

Actually there is an entire (and short) book dedicated to Gerrit and how to set-up replication and plugins.

Assuming you live in Italy, see the below link:

http://www.amazon.it/Learning-Gerrit-Code-Review-Milanesio-ebook/dp/B00EXNI5YI

however, I got to clone its repo:
$ git clone https://gerrit.googlesource.com/plugins/replication

Then I did this (why, oh, why are you guys using buck? never heard of it, it's not very helpful either) largely guessing what to do, because, again, there is no README that tells me how to build the plugin, and (as one might expect) it didn't work:

$ buck build :gerrit_plugin

OR
$ buck build :maven_jar

the outcome is still the same:

Parse error for build file /Users/mmassenzio/Development/replication/BUCK:   File "/Users/mmassenzio/Development/replication/BUCK", line 1, in <module>
    include_defs('//lib/maven.defs')
  File "/Users/mmassenzio/Development/replication/buck-out/tmp/buck_run.vTZA8o/buck8854395952966146876.py", line 584, in _include_defs
    implicit_includes=implicit_includes)
  File "/Users/mmassenzio/Development/replication/buck-out/tmp/buck_run.vTZA8o/buck8854395952966146876.py", line 687, in _process_include
    implicit_includes=implicit_includes)
  File "/Users/mmassenzio/Development/replication/buck-out/tmp/buck_run.vTZA8o/buck8854395952966146876.py", line 662, in _process
    with open(path, 'r') as f:
IOError: [Errno 2] No such file or directory: '/Users/mmassenzio/Development/replication/lib/maven.defs'

Unless you want to develop extensions on the replication plugin, you can simply install it during the "Gerrit init" phase when it asks "do you want to install replication plugin?" just say Y.

If you want to download a pre-build version, help yourself at https://gerrit-ci.gerritforge.com, all versions and flavours available pre-packaged and ready to be consumed :-)

As an aside, the other day I gave up trying to install the download_commands plugin exactly for the same reason: no documentation, no instructions on how to build/distribute it.

Again, just read what is available, doesn't take so much time.

In my book I covered the replication set-up step-by-step, using GitHub exactly as the easiest example to implement.

As a Gerrit user, is there a simple way to install plugins without incurring the cost of becoming familiar with (a) buck (seriously, guys, Maven or Gradle are just fine :), (b) the Gerrit plugin system and (c) whatever else is necessary to learn?

There is actually the "plugin-manager" project which will enable the "one-click" install experience. It isn't available yet as it needs more extra work.

All I'd really like to do is to use Gerrit as our team's code review tool (which I really really like and I think it's awesome, but am reluctantly coming to the conclusion it's just too much work to setup).

Why don't you start with a pre-built and pre-installed Docker image or just use a native packaging?

See:

https://gitenterprise.me/2015/04/30/no-more-tears-with-gerrit-code-review-thanks-to-docker/

and

https://gitenterprise.me/2015/02/27/gerrit-2-10-rpm-and-debian-packages-available/

Hope this helps.

Luca.

[lucamilanesio]

Hi Marco,

I've pushed a new fix [1] to the Gerrit native packaging that will improve a lot the "out-of-the-box" experience for new users.

New Gerrit packages will include the Gerrit plugin-manager, that will allow to see the list of "compatible" plugins available and then install them with a simple click.

Additionally it will be possible to "package" a Gerrit RPM (or DEB) with a customised set of plugins already included and pre-insatlled.

Currently only the "core-plugins" are packaged in Gerrit, making then difficult to install them at later time (as you noticed) or to discover, build and install other extra ones :-(

With the new packaging ... no more tears on plugins discovery, build and install :-)

Hope it will not be too late for your Gerrit POC ;-)

Luca.

[1] https://gerrit-review.googlesource.com/#/c/77434/

To unsubscribe, email repo-discuss+unsubscribe@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+unsubscribe@googlegroups.com.

[Marco Massenzio]

Ciao, Luca.

Thanks for that, and thanks everyone else who helped out (your suggestions worked!)

Unfortunately, we decided not to progress in the use of Gerrit, in that we felt the integration with our own Github Enterprise was too difficult to maintain and it would have been easy to mess things up in a way that would be difficult to entangle.

It's a rather large team with a diverse background and not everyone is entirely comfortable with git/code reviews.

The way I summarized it, was:

TL;DR: Gerrit is a great code review tool, but it does not integrate well (or, possibly, at all) with GitHub Enterprise.

If anyone here is interested in learning more, I'm happy to elaborate - but, in essence, my original intuition that Gerrit was a great code review tool is correct; and I totally appreciate that acting as the "repo source of truth" was the original development goal, so that's just fine.

Hope this helps, thanks again all involved for the help and making Gerrit freely available!

-- 
Marco Massenzio

http://codetrips.com

[1] https://gerrit-review.googlesource.com/#/c/77434/

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.

[Luca Milanesio]

Hi Marco,

comments in-line.

On 10 May 2016, at 23:16, Marco Massenzio <m.mas...@gmail.com> wrote:

Ciao, Luca.

Thanks for that, and thanks everyone else who helped out (your suggestions worked!)

Unfortunately, we decided not to progress in the use of Gerrit, in that we felt the integration with our own Github Enterprise was too difficult to maintain and it would have been easy to mess things up in a way that would be difficult to entangle.

I would agree that managing a repos spread across Gerrit and GHE is problematic.

I cannot mention how many times on GerritHub.io teams end up with a bit of a mess because people pushed directly to GitHub without going through code-review :-(

My suggestion would always be: if you decide to go the Gerrit-way, just make GHE read-only to everybody and use it as dumb Git Server replica.

The only issue with my statement is: hard to justify to the business a "Git Server replica" that costs up to 1M $ per year :-O

It's a rather large team with a diverse background and not everyone is entirely comfortable with git/code reviews.

This is a very different point: if your Team isn't ready or committed to code reviews, Gerrit can be quite difficult to digest.

Gerrit isn't very difficult to learn ... but it is not a piece of cake :-(

The way I summarized it, was:

TL;DR: Gerrit is a great code review tool, but it does not integrate well (or, possibly, at all) with GitHub Enterprise.

Not really true: look at GerritHub.io :-) you reuse:

- GitHub logins and SSO sessions

- GitHub Teams and Organisations

- GitHub repositories

- GitHub Pull Requests

... the only missing bit is the automatic sync of security between the two and the issues integration.

If anyone here is interested in learning more, I'm happy to elaborate - but, in essence, my original intuition that Gerrit was a great code review tool is correct; and I totally appreciate that acting as the "repo source of truth" was the original development goal, so that's just fine.

Hope this helps, thanks again all involved for the help and making Gerrit freely available!

This is a *very* good advantage ... 1M $ of Budget savings that can be reinvested in more code-quality, contributions to OpenSource, more project features ... or even just donate to charity :-)

Luca.