[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-02-28 6:02:03
Message-ID: CA+XidOHugTe94qxd6UCc_y3Q_saHqCyb2p9cO7q8jnX6AaL5KA () mail ! gmail ! com
[Download RAW message or body]

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-submi=
t-a-merge-request workflow, so in steps 3 and 4, people without commit acce=
ss 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 re=
motes 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 <somethi=
ng>
> >  > 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 na=
mes
> >  > 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)

>
> Regards,
>  - Michael Pyne

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