Add CircleCI build config

[WebDrake]

This patch adds a basic CircleCI config file in line with the suggested setup provided by https://tutorials.ubuntu.com/tutorial/continuous-snap-delivery-from-circle-ci

This version implements only the build stage, and does not attempt to push releases to the snap store; this will still be taken care of for now by the Launchpad build system. Its intended usage is to test PRs and the current state of release branches.

[WebDrake]

This will need some setup on the CircleCI side of things before it can be finalized. My one concern here is that because the build is long, it might use up limited resources. @kinke can you advise what will be necessary here?

[kinke]

Sorry for the delay. What does the snapcraft command do, in a nutshell? Doing a multilib build, running all tests and then packaging it up?

Wrt. Circle setup, I can't invite you directly via GUI due to invalid email address; I can add you as member of ldc-developers there if you sign up manually. You don't need to if you don't want to though, I can add the ldc2.snap project there for you with a mouse click. You can specify all you need directly in the yml file; only exception being secret tokens, which are set as protected environment variables in the Circle GUI.

[WebDrake]

Woah, this really took too long to follow up on.

snapcraft will:

• install a bunch of build dependencies using apt
• load source for LLVM and LDC from git
• build LLVM, a bootstrap 0.17.x LDC, and the LDC version we really want to build
• run the LDC tests

It's likely to be a long build (thanks to the tests).

I'm fine with the idea of you just turning on CircleCI for ldc2.snap. In the short term, is it possible to limit it to just PRs? It's probably overkill to run it on release branches too given that we already have setup with launchpad to handle that (although in the long run I might aim to use CircleCI for everything).

[kinke]

That'll take quite a while indeed, something like 100 minutes (sum of CircleCI LLVM + LDC CI jobs, which basically do the same). I'm not sure what the CircleCI job time-outs are; I'm currently experimenting with Azure pipelines, which offers a 6h time-out (but the machines are probably slower than Circle).

I'm not sure I fully grasped the advantage of these snap packages (well, except for a somewhat shorter command line compared to download+extract, at the cost of another package manager installation); in what way do they differ from our regular prebuilt packages? Those binaries are mostly linked statically (e.g., C++ runtime and LLVM) and should have very few dependencies; they are currently built on Ubuntu 14.04 (soon 16.04) with a backported gcc 6. If compatible, you might be able to use at least our prebuilt LLVM package (=> static libs for linking) and save substantial time.

In the short term, is it possible to limit it to just PRs?

That's all configurable in the yml file, there are corresponding environment variables to check how the build is triggered.

[kinke]

The webhook is now enabled; an amend or a new PR may be enough to trigger the 1st build, otherwise the config will have to land in a branch first.

[WebDrake]

I'm not sure I fully grasped the advantage of these snap packages (well, except for a somewhat shorter command line compared to download+extract, at the cost of another package manager installation); in what way do they differ from our regular prebuilt packages?

There may be some minor differences in terms of exact targets or features enabled, but beyond that, the difference is in convenience of use across distros: it makes it trivially easy to install different compiler versions and switch between them, and to receive updates, e.g.:

sudo snap install --classic --channel=stable ldc2 # installs latest stable package of LDC, will be updated when new versions to arrive
sudo snap refresh --classic --channel=1.9/stable ldc2   # switches to latest stable package of LDC v1.9.x
sudo snap refresh --classic --channel=1.8/stable  # switches to latest stable package of LDC v1.8.x

So it offers quite a lot of control in terms of both receiving automated updates when new package versions are released, but also sticking within a particular compiler release track, or switching between release tracks trivially from the command line.

[WebDrake]

Assuming things are set up for PRs now, I'm going to propose closing this PR, rebasing on top of 1.10, and opening a new PR (it'll be simpler than rebasing and retargeting the PR, which might cause some issues for CI).

[kinke]

So it offers quite a lot of control in terms of both receiving automated updates when new package versions are released, but also sticking within a particular compiler release track, or switching between release tracks trivially from the command line.

Sticking with a particular release track? We have almost no point releases, especially now with the ~2months release cycle. I'm not sure on which distros the regular prebuilt archives don't work, but other than that, the dlang install script seems to offer the same cmdline convenience, except that it features all versions, incl. the very latest successful CI builds.