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