Reducing build times of ldc-build-runtime
noone at nowhere.com
Thu Mar 19 14:28:39 UTC 2020
On Thursday, 19 March 2020 at 10:22:31 UTC, Petar Kirov
> On Wednesday, 18 March 2020 at 16:25:56 UTC, Jacob Carlborg
>> On 2020-03-17 22:33, kinke wrote:
>>> Yeah, 45 minutes is pretty short (and 11 minutes to compile
>>> LDC very slow). An x86 simulator for Azure CI or so would be
>>> pretty much unrestricted (6h time-out...).
>> With the free plan for closed source projects you only get 10
>> minutes for each build. That won't get you far.
> A bit off-topic, but how does it compare to other services like
> Azure Pipelines, GitHub Actions, BuildKite, etc. that support
> self-hosted runners? (Also the first two have free macOS
> runners and Windows runners.) From a quick look through the
> page they indeed offer many features tailored to mobile dev,
> but at least for work, I wouldn't choose a CI solution that
> doesn't offer support for self-hosting runners.
For work, I wouldn't choose any cloud solution at all. E.g.,
Azure has been a major pain in the ass the last week - python.exe
not in PATH for some hours/days, afterwards PRs and pushes not
triggering builds automatically for 2-3 days, and after that,
I've had to create a new 'service connection' via GitHub PAT in
order to successfully upload artifacts to the GitHub releases
again. In the meantime, the MS apt servers like to fail from time
to time due to checksum failures (yes, always the MS ones), so
that `apt-get update` fails etc.
So if possible, I'd prefer to have an existing CI service be
extended by a new iOS job, for a reduced maintenance burden.
Azure's Mac VMs are quad-cores (unlike GitHub Actions for
example, which only offer dual-cores; LDC compiles in under 4
mins) and ship with Xcode + simulators, see
More information about the digitalmars-d-ldc