Gerrit and Gitblit are both using a JGit engine for accessing the repository: if they are both in separate JVMs they will always get their in-memory cache out-of-synch.
When they are sharing the same repo, they have to share the same JGit cache :-) (otherwise you'll get very nasty behaviours) Luca. On 31 Mar 2014, at 10:13, Paul Fremantle <[email protected]> wrote: > Luca > > Can you please explain a bit more? > > Thanks > Paul > > > On 31 March 2014 10:11, Luca Milanesio <[email protected]> wrote: > Hi Dimuthu, > it is your decision and your business for sure ... but approach #2 does not > scale and work well :-) > > Do you have any Gerrit or Gitblit coding experience ? > > Luca. > > On 31 Mar 2014, at 09:02, Dimuthu Upeksha <[email protected]> wrote: > >> Hi all, >> >> Currently App Factory doesn't support for code reviewing functionalities. We >> are expecting to provide support to integrate existing code review tools to >> App Factory. >> >> Currently available code review tools >> >> 1. Pre commit tools >> Gerrit >> >> 2 Post commit tools >> Crucible >> Barkeep >> Phabricator >> >> I initiated a discussion in engineering group mail thread to clarify >> requirements. >> >> Summary. >> >> App factory should support both types of (post and pre commit) review tools >> according to customer demand. >> Because these two types work in different workflows it is required to >> consider them as two separate requirements. >> Gerrit is one of the most popular review tools. So as the first phase I'll >> integrate Gerrit with app factory. >> >> Currently app factory uses Gitblit as the git implementation to manage Git >> repositories. >> >> Gerrit uses it’s own local repository to handle code reviews >> >> If we need to integrate Gerrit as a code review tool for App Factory, there >> are two approaches >> >> 1. Remove Gitblit and replace Gerrit with Gitblit plugin. This acts as a >> git management tool and a review tool at same time >> >> <Approach_1.png> >> >> Pros >> >> Conceptually simple to manage git repositoris and reviews because all are in >> an one implementation >> >> Cons >> >> App factory has its own server side git hooks written in Gitblit. In this >> scenario because Gitblit act as a plugin inside gerrit, those hooks may not >> work. So we need to write hooks to gerrit to do that work >> >> Need to do considerable amount of architectural changes in repository >> creational phase. This avoids from providing support to integrate other >> review tools because repository creation is tightly coupled into Gerrit >> architecture >> >> >> 2. Keep Gerrit as default App Factory implementation and connect Gitblit’s >> git repository to a separately hosted Gerrit server >> >> <Approach_2.png> >> >> In this case Gitblit runs separately and Gerrit runs separately. Only >> connection is the shared repository. >> >> Pros >> >> No need to change gitblit’s server side hooks. >> >> Provide capability to integrate another review tool in future because Gerrit >> is loosely coupled with app factory repository creation flow >> >> Cons >> >> Implementation is much harder because repository should be manually >> synchronized by app factory. Ex: When we create an App, a git repository is >> created in Gitblit’s data folder. So app factory should inform gerrit that a >> new repository is created. Only then gerrit is aware of that repository. >> This notification should be done by app factory. >> >> There are areas we still haven’t tested. Ex : Forking >> >> >> Considering above facts I selected second approach because >> >> 1. This does minimal effect to existing app factory flow. >> 2. Provide ability to integrate another review tools with minimum changes >> >> >> Events that are needed to handle from app factory side >> >> <Architecture.png> >> >> At deployment >> >> Gerrit’s repository reference is mapped to Gitblit’s repository location. >> >> At user authentication >> >> Gerrit can be directly connected to App factory ldap server. >> >> At tenant creation >> >> Gerrit has the concept of groups. Currently it can’t handle tenants. We can >> reuse this groups concept to implement tenant awareness inside Gerrit >> >> Eg : >> Tenant name : tenant.com >> Roles : Admin, Developer, QA, DevOps >> >> We can create four Gerrit groups to represent above roles and assign >> necessary permission to each group (Done through API) >> >> tenant.com_admin >> tenant.com_developer >> tenant.com_qa >> tenant.com_devops >> >> >> At user creation >> >> Each user contains in a particular tenant. When a user is created >> considering its role, it is added to above groups. (Done through API) >> >> At App creation >> >> Normal flow is followed up to repository creation step. >> >> Once repository creation is done, update Gerrit about the repository via its >> APIs. This should be done because Gerrit keeps it’s own database that keeps >> metadata of each repository. If we don’t do that Gerrit doesn’t know whether >> there is such repository. >> >> Add groups to newly created repository (tenant.com_admin, >> tenant.com_devloper, etc ..) (Done through API) >> >> Thanks >> Dimuthu >> >> -- >> Dimuthu Upeksha >> Engineering Intern >> WSO2 inc. >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > > > -- > Paul Fremantle > CTO and Co-Founder, WSO2 > OASIS WS-RX TC Co-chair, Apache Member > > UK: +44 207 096 0336 > US: +1 646 595 7614 > > blog: http://pzf.fremantle.org > twitter.com/pzfreo > [email protected] > > wso2.com Lean Enterprise Middleware > > Disclaimer: This communication may contain privileged or other confidential > information and is intended exclusively for the addressee/s. If you are not > the intended recipient/s, or believe that you may have received this > communication in error, please reply to the sender indicating that fact and > delete the copy you received and in addition, you should not print, copy, > retransmit, disseminate, or otherwise use the information contained in this > communication. Internet communications cannot be guaranteed to be timely, > secure, error or virus-free. The sender does not accept liability for any > errors or omissions. > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
