Use Dhall for configuring the continuous integration

Motivation

After some discussion with @alp, I hacked up a preliminary conversion of .gitlab-ci.yml to Dhall. Were you in the know of the inner workings of the CI set-up—and were you wishing to systematically refactor the YAML of said set-up—please take over what I have done so far. Indeed, the conversation done here is shallow and naive, since I have no idea of how the CI machines are ran; hence my wish to let someone else check the new configuration and amend it so that it could be successfully deployed.

Proposal

The Dhall expressions are organised as summarised below.

.
├── LICENSE                   As it says on the tin (AISOTT)
├── artifact.dhall            Lifetimes and locations of build artefacts
├── ci-variables.dhall        AISOTT
├── default-ci-rules.dhall    AISOTT
├── field-builds.dhall        There are various kinds of builds going on in the CI; these I identified as being the
│                             most likely to deserve the generic name “builds”.
├── field-images.dhall        Mostly Docker configuration, apparently
├── field-linters.dhall       Mostly linters, apparently
├── field-releases.dhall      “builds” promoted to release-quality levels, apparently
├── include.dhall             Avoid carrying around relative paths for some of the `.dhall` files
├── platform.dhall            Characteristics of systems on which CI is ran
├── prelude.dhall             The Dhall Prelude in its eighteenth version
├── rule.dhall                A CI control flow construct, apparently
└── scripts/                  Bash scripts needed by some of the builds

Assuming you have a dhall-to-yaml on the PATH, you could generate the YAML data corresponding to the above expressions by issuing this shell command:

echo "{ builds   = ./field-builds.dhall \
      , images   = ./field-images.dhall \
      , linters  = ./field-linters.dhall \
      , releases = ./field-releases.dhall }" | dhall-to-yaml

Tarball of the Dhall expressions