Many caches at different levels: - SHA1 objs - Repos meta - Repos list Sent from my iPhone
> On 31 Mar 2014, at 11:06, Dimuthu Upeksha <[email protected]> wrote: > > 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
