Experiences with self-hosted git servers

[Philip M. Gollucci]

I actually know some github staff.  I can also say with first hand
knowledge from capital one that self hosted github enterprise does sso with
saml or auth.
Even if run in AWS.

What breaks is the integrations to everything because your endpoint is
different and you likely have a perimeter blocking things.




On Tue, Feb 4, 2020 at 10:37 AM Adriaan de Groot <adridg at freebsd.org> wrote:

> On Tuesday, 4 February 2020 15:37:57 CET Ed Maste wrote:
> > There are a number of options for self-hosting, such as Gitea, GitLab,
> > as well as git's plain built-in server. Phabricator (which we use for
> > code reviews) also includes a repository hosting module named
> > Diffusion.
> >
> > I am interested in hearing from FreeBSD users and developers who have
> > used one or more of these, or other Git hosting tools - what worked
> > well, what didn't? What do you wish you had known before getting
> > started?
>
> With my KDE hat on (yet my FreeBSD mail address): talk to KDE sysadmin
> (part
> of whom I'm BCCing).
>
> We migrated from SVN to git a few years ago, and first did cgit (that's
> git's
> internal server, I think) plus reviewboard; then cgit plus phabricator;
> now
> we're migrating to GitLab and dropping cgit and phabricator. That last
> migration is taking a while.
>
> KDE differs from FreeBSD in that we have about 300 repositories (one for
> each
> bit of KDE software) rather than a small number of really big repo's (e.g.
> src, ports). There is a vaguely similar mechanism of "joining the project"
> and
> code-review is generally enforced by social contract, like in FreeBSD
> ports.
>
> GitLab is generally pretty responsive in working with larger Free Software
> projects; it is used by KDE and Gnome in that way, who have their
> self-hosted
> Community Edition GitLabs to work with, more-or-less integrated with their
> own
> identity provider systems. Having a web-based workflow, that also supports
> drive-by-contributions, is seen as a bonus over plain git + phab.
> Especially
> Phabricator seems to be a drag on potential-new-contributors (and I'm not
> sure
> if it's developed anymore, which is one of the reasons KDE is switching
> away
> from it).
>
> Mainly for the move to GitLab:
>
>  - figure out what role issues will play; are those for reviews? Developer
> planning? bug reports? How do they align with Bugzilla use?
>  - figure out a branching strategy; what kind of private branches do you
> want?
> where are force-pushes allowed (eg. when rebasing or re-doing a patchset)?
> squash or maintain development history? commit to master only?
>  - think about a labels- and tags-scheme;
>
> [ade]

-- 
Philip M. Gollucci
IT Executive and Engineering Leader
http://www.linkedin.com/in/pgollucci/
301.818.0719