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