Hi Luca. Thanks for the feedback. For our scenario we did a POC and that went fine. What we did was,
- Cloned a project from Gitblit - Did some changes and pushed it back to Gerrit - Changes were appeared in Gerrit side for reviewing and we approved those changes - We could see changes merged by Gerrit from Gitblit side. Also we did testing when we roll back changes from Gerrit for re-reviewing and Possible code conflicts happen when we push code from both Gerrit and Gitblit at same time (But this is not relevant for our requirement) We haven't tested cache synchronising issue yet. We will look in to that also. What are the things that cache holds? Repository metadata? Thanks Dimuthu On Mon, Mar 31, 2014 at 2:48 PM, Luca Milanesio <[email protected]>wrote: > 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 > > -- Dimuthu Upeksha Engineering Intern WSO2 inc.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
