On CI
Friends, I've been looking at CI recently again, as I was facing CI turnaround times of 9-12hs; and this just keeps dragging out and making progress hard. The pending pipeline currently has 2 darwin, and 15 windows builds waiting. Windows builds on average take ~220minutes. We have five builders, so we can expect this queue to be done in ~660 minutes assuming perfect scheduling and good performance. That is 11hs! The next windows build can be started in 11hs. Please check my math and tell me I'm wrong! If you submit a MR today, with some luck, you'll be able to know if it will be mergeable some time tomorrow. At which point you can assign it to marge, and marge, if you are lucky and the set of patches she tries to merge together is mergeable, will merge you work into master probably some time on Friday. If a job fails, well you have to start over again. What are our options here? Ben has been pretty clear about not wanting a broken commit for windows to end up in the tree, and I'm there with him. Cheers, Moritz ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: On CI
Hi Moritz, I, too, had my gripes with CI turnaround times in the past. Here's a somewhat radical proposal: - Run "full-build" stage builds only on Marge MRs. Then we can assign to Marge much earlier, but probably have to do a bit more of (manual) bisecting of spoiled Marge batches. - I hope this gets rid of a bit of the friction of small MRs. I recently caught myself wanting to do a bunch of small, independent, but related changes as part of the same MR, simply because it's such a hassle to post them in individual MRs right now and also because it steals so much CI capacity. - Regular MRs should still have the ability to easily run individual builds of what is now the "full-build" stage, similar to how we can run optional "hackage" builds today. This is probably useful to pin down the reason for a spoiled Marge batch. - The CI capacity we free up can probably be used to run a perf build (such as the fedora release build) on the "build" stage (the one where we currently run stack-hadrian-build and the validate-deb9-hadrian build), in parallel. - If we decide against the latter, a micro-optimisation could be to cache the build artifacts of the "lint-base" build and continue the build in the validate-deb9-hadrian build of the "build" stage. The usefulness of this approach depends on how many MRs cause metric changes on different architectures. Another frustrating aspect is that if you want to merge an n-sized chain of dependent changes individually, you have to - Open an MR for each change (initially the last change will be comprised of n commits) - Review first change, turn pipeline green (A) - Assign to Marge, wait for batch to be merged (B) - Review second change, turn pipeline green - Assign to Marge, wait for batch to be merged - ... and so on ... Note that (A) incurs many context switches for the dev and the latency of *at least* one run of CI. And then (B) incurs the latency of *at least* one full-build, if you're lucky and the batch succeeds. I've recently seen batches that were resubmitted by Marge at least 5 times due to spurious CI failures and timeouts. I think this is a huge factor for latency. Although after (A), I should just pop the the patch off my mental stack, that isn't particularly true, because Marge keeps on reminding me when a stack fails or succeeds, both of which require at least some attention from me: Failed 2 times => Make sure it was spurious, Succeeds => Rebase next change. Maybe we can also learn from other projects like Rust, GCC or clang, which I haven't had a look at yet. Cheers, Sebastian Am Mi., 17. Feb. 2021 um 09:11 Uhr schrieb Moritz Angermann < moritz.angerm...@gmail.com>: > Friends, > > I've been looking at CI recently again, as I was facing CI turnaround > times of 9-12hs; and this just keeps dragging out and making progress hard. > > The pending pipeline currently has 2 darwin, and 15 windows builds > waiting. Windows builds on average take ~220minutes. We have five builders, > so we can expect this queue to be done in ~660 minutes assuming perfect > scheduling and good performance. That is 11hs! The next windows build can > be started in 11hs. Please check my math and tell me I'm wrong! > > If you submit a MR today, with some luck, you'll be able to know if it > will be mergeable some time tomorrow. At which point you can assign it to > marge, and marge, if you are lucky and the set of patches she tries to > merge together is mergeable, will merge you work into master probably some > time on Friday. If a job fails, well you have to start over again. > > What are our options here? Ben has been pretty clear about not wanting a > broken commit for windows to end up in the tree, and I'm there with him. > > Cheers, > Moritz > ___ > 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
Re: On CI
At this point I believe we have ample Linux build capacity. Darwin looks pretty good as well the ~4 M1s we have should in principle also be able to build x86_64-darwin at acceptable speeds. Although on Big Sur only. The aarch64-Linux story is a bit constraint by powerful and fast CI machines but probabaly bearable for the time being. I doubt anyone really looks at those jobs anyway as they are permitted to fail. If aarch64 would become a bottle neck, I’d be inclined to just disable them. With the NCG soon this will likely become much more bearable as wel, even though we might want to run the nightly llvm builds. To be frank, I don’t see 9.2 happening in two weeks with the current CI. If we subtract aarch64-linux and windows builds we could probably do a full run in less than three hours maybe even less. And that is mostly because we have a serialized pipeline. I have discussed some ideas with Ben on prioritizing the first few stages by the faster ci machines to effectively fail fast and provide feedback. But yes. Working on ghc right now is quite painful due to long and unpredictable CI times. Cheers, Moritz On Wed, 17 Feb 2021 at 6:31 PM, Sebastian Graf wrote: > Hi Moritz, > > I, too, had my gripes with CI turnaround times in the past. Here's a > somewhat radical proposal: > >- Run "full-build" stage builds only on Marge MRs. Then we can assign >to Marge much earlier, but probably have to do a bit more of (manual) >bisecting of spoiled Marge batches. > - I hope this gets rid of a bit of the friction of small MRs. I > recently caught myself wanting to do a bunch of small, independent, but > related changes as part of the same MR, simply because it's such a > hassle > to post them in individual MRs right now and also because it steals so > much > CI capacity. >- Regular MRs should still have the ability to easily run individual >builds of what is now the "full-build" stage, similar to how we can run >optional "hackage" builds today. This is probably useful to pin down the >reason for a spoiled Marge batch. >- The CI capacity we free up can probably be used to run a perf build >(such as the fedora release build) on the "build" stage (the one where we >currently run stack-hadrian-build and the validate-deb9-hadrian build), in >parallel. >- If we decide against the latter, a micro-optimisation could be to >cache the build artifacts of the "lint-base" build and continue the build >in the validate-deb9-hadrian build of the "build" stage. > > The usefulness of this approach depends on how many MRs cause metric > changes on different architectures. > > Another frustrating aspect is that if you want to merge an n-sized chain > of dependent changes individually, you have to > >- Open an MR for each change (initially the last change will be >comprised of n commits) >- Review first change, turn pipeline green (A) >- Assign to Marge, wait for batch to be merged (B) >- Review second change, turn pipeline green >- Assign to Marge, wait for batch to be merged >- ... and so on ... > > Note that (A) incurs many context switches for the dev and the latency of > *at least* one run of CI. > And then (B) incurs the latency of *at least* one full-build, if you're > lucky and the batch succeeds. I've recently seen batches that were > resubmitted by Marge at least 5 times due to spurious CI failures and > timeouts. I think this is a huge factor for latency. > > Although after (A), I should just pop the the patch off my mental stack, > that isn't particularly true, because Marge keeps on reminding me when a > stack fails or succeeds, both of which require at least some attention from > me: Failed 2 times => Make sure it was spurious, Succeeds => Rebase next > change. > > Maybe we can also learn from other projects like Rust, GCC or clang, which > I haven't had a look at yet. > > Cheers, > Sebastian > > Am Mi., 17. Feb. 2021 um 09:11 Uhr schrieb Moritz Angermann < > moritz.angerm...@gmail.com>: > >> Friends, >> >> I've been looking at CI recently again, as I was facing CI turnaround >> times of 9-12hs; and this just keeps dragging out and making progress hard. >> >> The pending pipeline currently has 2 darwin, and 15 windows builds >> waiting. Windows builds on average take ~220minutes. We have five builders, >> so we can expect this queue to be done in ~660 minutes assuming perfect >> scheduling and good performance. That is 11hs! The next windows build can >> be started in 11hs. Please check my math and tell me I'm wrong! >> >> If you submit a MR today, with some luck, you'll be able to know if it >> will be mergeable some time tomorrow. At which point you can assign it to >> marge, and marge, if you are lucky and the set of patches she tries to >> merge together is mergeable, will merge you work into master probably some >> time on Friday. If a job fails, well you have to start over again. >> >> What ar