[U-Boot-Custodians] git access - move to gitlab?

[Tom Rini]

On Mon, Mar 25, 2019 at 04:28:02PM +0100, Michal Simek wrote:
> On 25. 03. 19 16:19, Tom Rini wrote:
> > On Mon, Mar 25, 2019 at 03:05:10PM +0100, Michal Simek wrote:
> >> On 25. 03. 19 13:56, Tom Rini wrote:
> >>> On Mon, Mar 25, 2019 at 01:35:05PM +0100, Wolfgang Denk wrote:
> >>>> Hi all,
> >>>>
> >>>> I guess a few of you will have noticed the recent issues with
> >>>> HTTP(S) access to the custodian repositories; recent versions of git
> >>>> have introduced changes which are incompatible with the way how
> >>>> "alternates" and "http-alternates" have been working for many years.
> >>>>
> >>>> For a quick fix, I have now repacked all the repositories and
> >>>> removed the alternates / http-alternates files, so cloning over
> >>>> HTTP(S) should be working again.
> >>>>
> >>>> However, I think this is just a quick fix, and not a long term
> >>>> solution.  The git.denx.de server itself is a bit oldish, and the
> >>>> gitweb setup running on git.denx.de is old and ugly and limited and
> >>>> slow...
> >>>>
> >>>> I would like to move all the custodian repos to our gitlab server.
> >>>> This is a more powerfull machine, and we would have a number of
> >>>> additional options there.  We can still provide "classic" git
> >>>> protocol access even under the old URLs.
> >>>>
> >>>> Are there any concerns about this?
> >>>>
> >>>> When would be a good point in time (in release schedule) for such a
> >>>> move?
> >>>>
> >>>> Do we have to migrate all repositories at once, or can we have a few
> >>>> "early adaptors" who serve as guinea pigs?
> >>>
> >>> The only concern I have is can we rewrite links like
> >>> https://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/howto.txt;h=8592719685eba10f72886e04b0b1ad9f91b3c61e;hb=HEAD
> >>> so they get redirected?  There's a lot of stuff like that floating
> >>> around that I'd like to have still be valid.  Thanks again!
> >>
> >> If you look at current custodian workflow then at least I push branch to
> >> github to be taken by travis to build and test there.
> >> Then I am pushing it to denx.de and sending pull request with signed tags.
> >>
> >> Is there a support for travis in gitlab?
> >> If not, I tend to say that maybe it is time to also send pull request
> >> from others repos out of denx.de.
> >> But definitely it is nice to have all these repos in the same location
> >> to also check what others are doing.
> > 
> > Travis-CI is unfortunately github-centric.  gitlab has its own CI stuff
> > which my first hesitation on is "do we really want to start melting some
> > DENX dev machines?" because the big selling feature on using travis is,
> > even if it's slow and network fails way more often than I'd like, it's
> > free, unlike doing builds on AWS/Google Compute/Azure.  One thing I have
> > looked into a little bit is that sr.ht doesn't yet, but plans to, allow
> > for using your own build HW with whatever time/threading restrictions
> > you want to allow on it.
> > 
> > That, or figuring out how to use gitlab's CI with specify a build
> > machine/cluster might be a further improvement.
> 
> I am not fan github at all for various reasons but if there is no value
> to move custodian trees to gitlab then why this should be done?

Ah, the value is in reducing the effort it takes Wolfgang/DENX to host
the trees.  We're a special one-off now and this would let us get folded
into their normal hosting flow as I understand it.

> I am not quite sure if there is any existing restriction that pull
> request should be just from repos at current git server but if people
> want to move gitlab then they should move. If people want to use just
> github or whatever else they could use that too and sending PR from that
> locations.

For me, it's always been a rule-of-thumb and not a hard requirement that
PRs come from git.denx.de rather than anywhere else.

Has anyone used gitlab's CI?  Since we started using it internally
recently it's on my TODO list to look at it.  My very quick takeaway is
you can tell it to build $wherever and I'm tempted to see how much it
costs per run on cloudy services but also how hard it would be to
provide a template for "run it yourself".  My workstation is an old Dell
Precision T3600 and that is so much quicker than Travis so maybe we move
from grumbly-but-free service to self-hosted similar.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot-custodians/attachments/20190325/1889a424/attachment-0001.sig>