digitalmars.D - Auto-tester CI transition
Hi all, I'm sure anyone who has ever contributed to D on GitHub is familar with the auto-tester (https://auto-tester.puremagic.com) and has been a crucial piece in D's build infrastructure. I think all core and casual contributors have their own horror stories about the auto-tester to share, so I'm just giving a high-level overview that while Brad did a fantastic job by creating this custom-made tool for the D community, it's also a lot harder to work with than any third-party CI solution as no D contributor has access to it (e.g. to install/update software, ssh-ing to debug failures, ...). Moreover, maintaining a reliable CI is a difficult job and many companies have full-time engineering teams dedicated to this and we had our more than fair share of problems with the auto-tester. It has long been discussed and decided that we should move to a different CI solution over which contributors have more control and as we're yet again struggling with it (see e.g. [2]), we are finally trying to make this happen: https://github.com/dlang/dmd/pull/11653. Hence, anyone who objects to this transition should speak up now. Plan ---- 1) The first step is to disable the Windows builds as they are already fully replicated by Azure pipelines (or will be with the proposed PR). This is the most important step as we want to "unbreak" the PR queues. 2) Move Linux + OSX builds to e.g. Travis, CircleCi or Buildkite 3) Move FreeBSD builds. Historically, this has been the blocker for the migration. However, LDC is using CirrusCI successfully and if this doesn't work out for DMD, we can always run FreeBSD VMs with Buildkite agents installed. Best, Seb PS: auto-tester is about to celebrate its tenth birthday in a few days [2]. [1] https://github.com/dlang/druntime/pull/3202 [2] https://github.com/braddr/at-client/commit/b81de1ab2059c45c18dc2b83eb60712b83a8c134
Aug 30 2020
kinke <noone nowhere.com> On Sunday, 30 August 2020 at 22:16:00 UTC, Seb wrote:[...]Excellent. Wrt. CirrusCI, I recommend not just looking at it for FreeBSD, but in general. Especially https://cirrus-ci.org/faq/#are-there-any-limits - e.g., I'm using 2 simultaneous Linux containers with 8 CPU cores and 16 GB each (16 CPU cores is the current limit for Linux, it even used to be 64!), and they're *fast*. Also, the limits don't apply to the repo, but to the GitHub user triggering the build - which means that if 10 different contributors push at the same time, 160 Linux cores are available!
Aug 30 2020