[GHC DevOps Group] GitLab migration status
simon.jakobi at googlemail.com
Mon Dec 17 08:17:18 UTC 2018
in my experience Gitlab has been extremely slow at showing commit diffs to
the point that it gives up and returns a 502:
Is this possibly related to any resource constraints on our instance?
Am Mo., 17. Dez. 2018 um 06:29 Uhr schrieb Ben Gamari <ben at well-typed.com>:
> TL;DR. Given somewhat slower-than-expected progress on the Trac import I
> suggest that we implement a pared-down migration on Tuesday.
> See "The Plan" below.
> Hello everyone,
> Over the last few weeks we have been hard at work preparing the
> migration to GitLab. Currently the following things are ready:
> * Hosting of GHC's repositories and those of its mirrors have been
> * Continuous integration has been configured for GHC.
> All-in-all the GitLab migration has been quite timely since we were
> recently notified by CircleCI of billing changes which will soon make
> it quite difficult for us to continue using their services (see the
> thread on ghc-devops for details).
> Thankfully, moving CI to GitLab has been mostly painless and has
> even enabled us to introduce testing of platforms which were
> previously inaccessible to us under CircleCI.
> * The various linters which previously ran via `arc lint` and gitolite
> post-receive hooks have been ported to CI jobs.
> * The Trac ticket migration is looking good although there are still a
> significant number of details which need to be sorted out.
> * The Wiki migration is in a similar state.
> Over the past weeks we have been in constant contact with GitLab's FOSS
> outreach group, who have been quite helpful in getting the eyes of
> GitLab employees on the issues affecting our transition. Thanks to
> especially to David Planella for his help so far.
> Unfortunately, there is one issue in particular  which is currently
> blocking the Trac migration. From my discussions with GitLab's upstream
> it sounds like it may be possible for them to prioritize a fix in the
> short-term. However, our aggressive migration timeline is a fair bit
> faster than GitLab's development cycle and consequently this certainly
> won't happen before our planned migration on Tuesday.
> # The Plan
> Given what remains to be done in the Trac migration I believe it would
> be a mistake to move ahead with the full migration as planned. However,
> in the interest of re-gaining functional continuous integration of
> patches as soon as possible I propose that we move ahead with moving
> code review on Tuesday.
> The plan would be as follows:
> 1. We setup the final gitlab.haskell.org instance tomorrow; since the
> Trac migration will not be run will need to create new accounts on
> 2. We begin officially accepting merge requests on this fresh GitLab
> instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will
> become GHC's official upstream repository.
> 3. We allow a week of transition time where new Differentials will
> continue to be accepted via Phabricator.
> 4. After this transition period we place Phabricator in read-only mode.
> 5. When we are confident in the Trac migration (likely after the new
> year) we move ahead with importing tickets and the wiki
> Previously I was skeptical of any plan that involved running the Trac
> migration against a live GitLab instance. However, further reflection
> I believe such a migration is safe and feasible. Moreover, given the
> constraints set upon us by the impending CircleCI changes, I think this
> is our best option to ensure continuity of CI.
> - Ben
>  https://gitlab.com/gitlab-org/gitlab-ce/issues/46980
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ghc-devops-group