[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2019-03-23 0:53:33
Message-ID: CA+XidOGCUEK7muOZuE+WAThAbj4DiFPCyTsrVVRnjstBze8FTQ () mail ! gmail ! com
[Download RAW message or body]

On Sat, Mar 23, 2019 at 12:42 AM Milian Wolff <mail@milianw.de> wrote:
>
> On Donnerstag, 28. Februar 2019 07:02:03 CET Ben Cooksley wrote:
> > On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne <mpyne@kde.org> wrote:
> > > On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote:
> > > >  ---- On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein <hein@kde.org> wrote
> > > >  ----
> > > >
> > > >  > On 2/27/19 4:38 AM, Nate Graham wrote:
> > > >  > > It's really pretty nice. But  Gitlab has a
> > > >  > > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3
> > > >  > > and 4, people without commit access won't just be able to start
> > > >  > > hacking with the source checkout that kdesrc-build downloads, or
> > > >  > > else they won't be able to push their branch to any remotes and
> > > >  > > create a Merge Request.> >  >
> > > >  > No, this is not correct.
> > > >  >
> > > >  > When you have a local git repository (be it your own or a clone), it
> > > >  > can
> > > >  > interact with any number of remote git repositories.
> > > >  >
> > > >  > When you do `git clone <something>`, git automatically adds
> > > >  > <something>
> > > >  > as a remote named "origin" to the local repository. But what "origin"
> > > >  > points to can be changed at any time, or other remotes with other
> > > >  > names
> > > >  > can be added for pushing too. "origin" is just a convention.
> > > >  >
> > > >  > I.e. someone can totally do this:
> > > >  > 1. use kdesrc-build to clone stuff
> > > >  > 2. git checkout -b feature to make a feature branch
> > > >  > 3. hack
> > > >  > 4. make a private fork on gitlab
> > > >  > 5. push to their fork from the clone they've been working in
> > > >  >
> > > >  > It's not necessary to fork first and clone your fork to get started.
> > > >
> > > > Thanks Eike, that makes e a lot of sense. Going to the website to fork
> > > > each repo for the first time still adds an additional manual step
> > > > compared to the status quo, so it would be nice if we can get
> > > > kdesrc-build so set up forks automatically. That would be really
> > > > slick.
> > >
> > > That would be slick. I wonder if Gitlab exposes an API for that (ideally
> > > something that doesn't involve kdesrc-build having to store your creds)?
> > > Potentially this API
> > > https://docs.gitlab.com/ee/api/projects.html#fork-project (though it's
> > > documented for EE not CE)?
> >
> > The API for both EE and CE is identical, except for the functionality
> > that is dependent on the edition of EE it is available in (which is
> > only enabled if you are using that edition)
> > With regards to credentials, you would need to give it an API Token yes.
> >
> > In terms of server load, it would be nice if the setup of forks was
> > still something the developer had to initiate rather than being done
> > automatically for every repository touched by kdesrc-build (I say this
> > mainly as if we had 50 people fork just half of the mainline
> > repositories we have, that's ~450GB of space used up - a massive
> > scalability issue)
>
> Are you sure about this? Isn't gitlab using something like `git-new-workdir`
> internally to save on the disk overhead? If not, then request it, that would
> be an obvious optimization opportunity.

I haven't checked, but at first glance it doesn't seem to do this
(which would make sense, because you're actually able to have multiple
Gitaly instances to store repositories for a single Gitlab instance).

In any case, i'd rather that we used fork in a manner that makes sense
rather than trying to optimise for something that ends up creating
thousands of repositories which are never used. We should only be
creating forks / repositories which are actually going to be used.

>
> Bye
>
> --
> Milian Wolff
> mail@milianw.de
> http://milianw.de

Regards,
Ben
[prev in list] [next in list] [prev in thread] [next in thread]