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 <[email protected]> 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 <[email protected]>, 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 <[email protected]>, 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 <[email protected]>, 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 <[email protected]>, 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 > >>>>>> <[email protected]>: > >>>>>> > >>>>>> 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 > >>>>>> [email protected] > >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > [email protected] > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
