Any ways to test a GHC build against large set of packages (including test suites)?

Thu Jul 25 14:17:47 UTC 2019

Hi Gert-Jan,

Have you considered using the head.hackage infrastructure? There is a
CI job which builds a set of package with HEAD. It is designed for
this kind of testing.

In order to test it on your branch you probably just need to it at a
suitable bindist.

Cheers,

Matt

On Thu, Jul 25, 2019 at 3:10 PM Gert-Jan Bottu
<gertjan.bottu at kuleuven.be> wrote:
>
> Hi,
>
> I'm trying to do something similar : I'm hacking around with GHC, and
> would like to build a large set of packages to verify my changes.
> Similarly to the steps described below, I've followed the scheduled
> build in .circle/config.yml, but I can't figure out how to force it to
> use my own (hacked upon) GHC build?
>
> More concretely, the steps I took (from the lastest .circle/config.yml):
> - Installed my local GHC to ~/ghc-head
> - Installed stackage-build-plan, stackage-curator and stackage-head from
> git repos
> - export BUILD_PLAN=nightly-2018-10-23
> - curl
> https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/metadata.json
> --output metadata.json
> - curl
> https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.yaml
> --output $BUILD_PLAN.yaml
> - fix-build-plan $BUILD_PLAN.yaml custom-source-urls.yaml
> - stackage-curator make-bundle --allow-newer --jobs 9 --plan-file
> $BUILD_PLAN.yaml --docmap-file docmap-file.yaml --target $BUILD_PLAN
> --skip-haddock --skip-hoogle --skip-benches --no-rebuild-cabal -v >
> build.log 2>&1
>
> This manages to build Stackage and generate a report just fine, but it
> doesn't use my ~/ghc-head GHC install. Any ideas how I can point
> stackage-curator to a specific GHC install?
>
> Thanks
>
> Gert-Jan
>
> On 10.08.18 10:39, Ömer Sinan Ağacan wrote:
> > Hi,
> >
> > This is working great, I just generated my first report. One problem is stm-2.4
> > doesn't compile with GHC HEAD, we need stm-2.5.0.0. But that's not published on
> > Hackage yet, and latest nightly still uses stm-2.4.5.0. I wonder if there's
> > anything that can be done about this. Apparently stm blocks 82 packages (I
> > don't know if that's counting transitively or just packages that are directly
> > blocked by stm). Any ideas about this?
> >
> > Ömer
> >
> > Ömer Sinan Ağacan <omeragacan at gmail.com>, 9 Ağu 2018 Per, 14:45
> > tarihinde şunu yazdı:
> >> Ah, I now realize that that command is supposed to print that output. I'll
> >> continue following the steps and keep you updated if I get stuck again.
> >>
> >> Ömer
> >>
> >> Ömer Sinan Ağacan <omeragacan at gmail.com>, 9 Ağu 2018 Per, 13:20
> >> tarihinde şunu yazdı:
> >>> Hi Manuel,
> >>>
> >>> I'm trying stackage-head. I'm following the steps for the scheduled build in
> >>> .circleci/config.yml. So far steps I took:
> >>>
> >>> - Installed ghc-head (from [1]) to ~/ghc-head
> >>> - Installed stackage-build-plan, stackage-curator and stackage-head (with
> >>>    -fdev) from git repos, using stack.
> >>> - export BUILD_PLAN=nightly-2018-07-30 (from config.yml)
> >>> - curl https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/metadata.json
> >>> --output metadata.json
> >>> - curl https://raw.githubusercontent.com/fpco/stackage-nightly/master/$BUILD_PLAN.yaml
> >>> --output $BUILD_PLAN.yaml
> >>>
> >>> Now I'm doing
> >>>
> >>> - ./.local/bin/stackage-head already-seen --target $BUILD_PLAN
> >>> --ghc-metadata metadata.json --outdir build-reports
> >>>
> >>> but it's failing with
> >>>
> >>>      The combination of target and commit is new to me
> >>>
> >>> Any ideas what I'm doing wrong?
> >>>
> >>> Thanks
> >>>
> >>> [1]: https://ghc-artifacts.s3.amazonaws.com/nightly/validate-x86_64-linux/latest/bindist.tar.xz
> >>>
> >>> Ömer
> >>>
> >>> Ömer Sinan Ağacan <omeragacan at gmail.com>, 7 Ağu 2018 Sal, 23:28
> >>> tarihinde şunu yazdı:
> >>>> Thanks for both suggestions. I'll try both and see which one works better.
> >>>>
> >>>> Ömer
> >>>>
> >>>> Manuel M T Chakravarty <chak at justtesting.org>, 7 Ağu 2018 Sal, 18:15
> >>>> tarihinde şunu yazdı:
> >>>>> Hi Ömer,
> >>>>>
> >>>>> This is exactly the motivation for the Stackage HEAD works that we have pushed at Tweag I/O in the context of the GHC DevOps group. Have a look at
> >>>>>
> >>>>>    https://github.com/tweag/stackage-head
> >>>>>
> >>>>> and also the blog post from when the first version went live:
> >>>>>
> >>>>>    https://www.tweag.io/posts/2018-04-17-stackage-head-is-live.html
> >>>>>
> >>>>> Cheers,
> >>>>> Manuel
> >>>>>
> >>>>>> Am 06.08.2018 um 09:40 schrieb Ömer Sinan Ağacan <omeragacan at gmail.com>:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'd like to test some GHC builds + some compile and runtime flag combinations
> >>>>>> against a large set of packages by building them and running test suites. For
> >>>>>> this I need
> >>>>>>
> >>>>>> - A set of packages that are known to work with latest GHC
> >>>>>> - A way to build them and run their test suites (if I could specify compile and
> >>>>>>   runtime flags that'd be even better)
> >>>>>>
> >>>>>> I think stackage can serve as (1) but I don't know how to do (2). Can anyone
> >>>>>> point me to the right direction? I vaguely remember some nix-based solution for
> >>>>>> this that was being discussed on the IRC channel, but can't recall any details.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Ömer
> >>>>>> _______________________________________________
> >>>>>> ghc-devs mailing list
> >>>>>> ghc-devs at haskell.org
> >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs