Great work, Ben! Thanks for all the hard work setting up this CI. My hopes are high that our contributions' quality and ease will go up.
There seem to be a few loose ends that need to be wrapped up, like redirect the mirroring of https://github.com/ghc/ghc/ towards GitLab and possibly switch on mirroring for http://git.haskell.org/ghc.git . Or should we just add a redirect? Should pull requests be blocked on the former? Anyway some readmes need to be adapted for the new world order. Cheers, Gabor On 12/27/18, Ara Adkins <m...@ara.io> wrote: > Congrats to Ben and everybody involved! This has been a long time coming and > I’m super excited to see what it means for GHC in the future! > > _ara > > On 27 Dec 2018, at 11:56, Matthew Pickering <matthewtpicker...@gmail.com> > wrote: > >>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >>> "fast-forward without a merge commit" merge strategy. >> >> Are merge requests squashed before they are merged? >> >> It seems that the answer by default is no.. >> https://gitlab.com/gitlab-org/gitlab-ce/issues/27956 >> >> and the reason being that upsteam prefers "Convention over >> Configuration".. >> https://about.gitlab.com/handbook/product/#convention-over-configuration >> >> However it seems that there is a per-mr option which can be checked if >> you are diligent to do it for each MR. Some comments indicate that >> it's possible to implement a webhook to change this behaviour. >> >> Matt >> >>> On Thu, Dec 27, 2018 at 6:28 AM Ben Gamari <b...@well-typed.com> wrote: >>> >>> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official >>> upstream GHC repository. Various introductory notes are >>> discussed. Let me know if you have any trouble. >>> >>> Also, please do verify the correctness of the email address >>> associated with your Trac account in the next few weeks. It will >>> be used to map users when we transition Trac tickets to GitLab. >>> >>> >>> >>> Hello everyone, >>> >>> I am happy to announce that CI on GHC's GitLab instance [1] is now >>> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be >>> considered the official upstream repository of GHC. >>> >>> The rest of this email is meant to serve as a brief introduction and >>> status update. It can also be viewed on the GitLab Wiki [2]. >>> >>> [1] https://gitlab.haskell.org/ >>> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome >>> >>> >>> # Getting started >>> >>> To get started on GitLab you will first want to either create a new >>> account >>> [1] or login with your GitHub credentials [2]. >>> >>> Once you have an account you should add an SSH key [3] so that you can >>> push >>> to your repositories. If you currently have commit rights to GHC notify >>> me >>> (Ben Gamari) of your user name so I can grant you similar rights in >>> GitLab. >>> >>> >>> [1] https://gitlab.haskell.org/users/sign_in >>> [2] https://gitlab.haskell.org/users/auth/github >>> [3] https://gitlab.haskell.org/profile/keys >>> >>> >>> # Updating your development environment >>> >>> You can updated existing working directory (assuming the usual upstream >>> remote name of `origin`) for the new upstream repository location by >>> running the following: >>> >>> git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git >>> git remote set-url --push origin g...@gitlab.haskell.org:ghc/ghc >>> >>> This is all that should be necessary; a quick `git pull origin master` >>> should verify that everything is working as expected. >>> >>> >>> # Continuous integration >>> >>> Continuous integration is now provided by GitLab's native continuous >>> integration infrastructure. We currently test a variety of >>> configurations, including many that neither Phabricator nor >>> CircleCI/Appveyor previously tested (see [1] for an example run): >>> >>> * With the make build system: >>> * x86_64/Linux on Fedora 27, Debian 8, and Debian 9 >>> * i386/Linux on Debian 9 >>> * aarch64/Linux on Debian 9 (currently broken due to a variety of >>> issues) >>> * x86_64/Windows >>> * x86_64/Darwin >>> * x86_64/Linux on Debian 9 in a few special configurations: >>> * unregisterised (still a bit fragile due to #16085) >>> * integer-simple >>> * building GHC with -fllvm >>> * With Hadrian: >>> * x86_64/Linux on Debian 9 >>> * x86_64/Windows (currently broken due to #15950) >>> >>> We also run a slightly larger set of jobs on a nightly basis. Note that >>> binary distributions are saved from most builds and are available for >>> download for a few weeks (we may put in place a longer retention policy >>> for some builds in the future). >>> >>> There are admittedly a few kinks that we are still working out, >>> particularly in the case of Windows (specifically the long build times >>> seen on Windows). If you suspect you are seeing spurious build failures >>> do let us know. >>> >>> To make the best use of our limited computational resources our CI >>> builds occur in three stages: >>> >>> * lint: the style and correctness checkers which would previously be >>> run by `arc lint` and `git push` >>> >>> * build: Debian 9 Linux x86_64 built with make and Hadrian >>> >>> * full-build: the remaining configurations >>> >>> If a build fails at an earlier phase no further phases will be run. >>> >>> >>> [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568 >>> >>> >>> # Structuring your merge request >>> >>> With the transition to GitLab GHC is moving to a model similar to that >>> used by GitHub. If you have a Differential on Phabricator we will finish >>> review there. However, please post new patches as merge requests on >>> GitLab. >>> >>> Note that Phabricator and GitLab have quite different models for >>> handling patches. Under Phabricator a Differential is a single patch >>> with no further structure; larger changes can be composed of multiple >>> dependent Differentials. >>> >>> Under GitLab's model a merge request is a git branch consisting of >>> one or more patches. Larger changes can be handled in one of two ways: >>> >>> a. a set of dependent merge requests, each of which to be squashed when >>> merged. >>> >>> b. a single branch with each atomic change made in a single, buildable >>> commit >>> >>> Due to the difficulty of maintaining dependent merge requests, I would >>> recommend that contributors making larger changes use method (b). >>> >>> >>> # Submitting your merge request for review >>> >>> Depending upon whether you have push rights to the GHC repository there >>> are two ways to submit a merge request: >>> >>> * if you have push access you can push a branch directly to >>> g...@gitlab.haskell.org:ghc/ghc.git and open merge request. >>> >>> In this case please do follow the usual branch naming conventions: >>> >>> * prefix all branch names with `wip/` >>> >>> * if you are fixing a particular ticket consider using the name >>> `wip/TNNNN` >>> >>> * if not you can create a fork using the "Fork" button on the project >>> page [1] and push your branch there >>> >>> In either case after you have pushed your branch open a merge request >>> against ghc/ghc [2]. >>> >>> [1] https://gitlab.haskell.org/ghc/ghc/forks/new >>> [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/new >>> >>> >>> # Reviewing and merging merge requests >>> >>> As always, all contributors are encouraged to help review proposed >>> changes. If you are unfamiliar with GitLab's review interface please see >>> GitLab's user documentation [1]. Here are a few quick highlights for >>> those who are familiar with GitHub but haven't yet used GitLab: >>> >>> * As with GitHub, GitLab supports both inline and out-of-line comments. >>> >>> * Comments that are actionable (known as "discussions") can be marked >>> as resolved and collapsed. >>> >>> * Comments can be left on both changed and unchanged lines >>> >>> * Revisions of a merge request can be viewed and compared using the >>> two drop-down menus at the top of the Changes tab >>> >>> * Merge requests can require approvals from particular users before >>> considered as mergable >>> >>> * Merge requests can be placed in "merge when CI passes" state, which >>> will cause merge requests to be merged as soon as they are green >>> >>> From this point onward all changes to GHC will be merged via >>> GitLab's merge requests facility and must pass CI before being merged. >>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's >>> "fast-forward without a merge commit" merge strategy. Consequently you >>> will be asked to rebase merge requests which are not fast-forward merges >>> before merging (a convenient "Rebase" button will appear if the rebase >>> can be carried out without conflicts. >>> >>> [1] https://gitlab.com/help/user/discussions/index.md#discussions >>> >>> >>> # Status of the Trac migration >>> >>> Tobias will be continuing work on the Trac ticket migration after a bit >>> of a holiday break. Hopefully by mid-January we will be able to move >>> forward on this part of the migration; I will share more details about >>> this as they develop. >>> >>> In the meantime, users of Trac should check and possibly update the >>> email address associated with their account [1]. This address will be >>> used to correlate Trac users with their GitLab equivalents so the >>> correctness of this address will be important in preserving attribution >>> information during the Trac import. >>> >>> [1] https://ghc.haskell.org/trac/ghc/prefs >>> >>> >>> # Next steps >>> >>> We are actively working on cleaning up a few remaining issues with CI: >>> >>> * build times are still very long on Windows, despite the fact that we >>> are only building the `quick` build flavour on that platform; >>> consequently GitLab CI Windows builds do sometimes timeout >>> when we are faced with long build queues. >>> >>> * we at times run low on disk space on our Windows builder runners, >>> resulting in occasional spurious build failures >>> >>> * Appveyor builds (which are supposed to supplement the native GitLab >>> builds) rarely seem to finish >>> >>> GitLab upstream has been incredibly supportive of our transition effort >>> and has expressed interest in assisting us with issues that we >>> encounter. Our current requests can be found on our migration effort's >>> tracking ticket [1]. If you find any additional bugs or workflows that >>> could be improved please do let me know and I can raise the matter with >>> GitLab. >>> >>> [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/55039 >>> >>> >>> # Acknowledgments >>> >>> I would like to acknowledge several parties for their contributions to >>> this effort: >>> >>> * Packet.net and Google X for their generous donation of hosting for >>> continuous integration and web hosting >>> >>> * GitLab and their Open Source program for many productive discussions, >>> their generous support, and the GitLab Ultimate license used by >>> gitlab.haskell.org. >>> >>> * Davean Scies for his help procuring the hosting services that power >>> our continuous integration. >>> >>> * Tweag.io for their offer of help and advice >>> >>> * Matthew Pickering, Alp Mestangullari, Tobias Dammers for their work >>> in setting up the new instance, sorting out the details of the >>> migration, and debugging problems when they arose >>> >>> Finally, thanks to GHC's contributors for their patience during this >>> transition; it has been a long process which has stolen a significant >>> amount of attention from other matters. My apologies we have been a bit >>> less responsive than usual in code review and ticket triage over the >>> past month or two. Regardless, I am hopeful that this wait will be >>> worthwhile. >>> >>> >>> # Final thoughts >>> >>> This is not only a milestone for the GitLab migration but also for GHC >>> itself. For the first time GHC has fully-automated testing, proposed >>> patch CI, and release generation across the full range of Tier 1 >>> configurations it supports, with passing builds in all cases. >>> >>> We are very excited to begin this next chapter of GHC's development and >>> are looking forward to your feedback on how we can further improve our >>> new infrastructure. Onward and upwards! >>> >>> Cheers, >>> >>> - Ben >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
