Thinktank: CI's, compiler lists, and project automation

[Jacob Carlborg]

On Friday, 2 March 2018 at 06:07:25 UTC, Nick Sabalausky 
(Abscissa) wrote:
> (I'm posting this here instead of D.learn because it isn't 
> really a "How to do XYZ in D?", but rather to invite discussion 
> on high-level solutions to a problem.)
>
> Here's a common problem:
>
> 1. A project (ex, some library) uses travis-ci (and/or other) 
> to ensure compatibility with a range of compiler versions. The 
> travis configuration file includes a manually-curated list of 
> compiler versions.
>
> 2. CI tests are triggered by new commits/merges/PRs in the 
> project.
>
> 3. New compiler versions are released.
>
> 4. Compiler updates may or may not trigger new tests with the 
> new compiler, depending on the project.
>
> 5. Project maintainer must manually update the list of 
> compilers. (And this isn't one task, but rather O(n), where 
> n=number of projects the given person is maintaining).
>
> The challenge: What is the best way to automate this? (ie, #4 
> and #5)

Travis CI allows you to specify a D compiler in the following 
ways:

* <compiler> - the latest version of the specified compiler
* <compiler>-beta - the latest beta
* <compiler>-nightly - the nightly build
* <compiler>-<version> - a specific version of the compiler

Where <compiler> is "dmd", "ldc" or "gdc".

Combine the above with a scheduled build that builds once every 
day you're pretty well covered. For an example, see the Travis CI 
configuration for DStep [1]. I'm building the latest version of 
DMD and LDC on Linux and macOS, but the betas and nightly are 
only built on Linux, due the the limited resources of macOS 
builds on Travis CI.

[1] 
https://github.com/jacob-carlborg/dstep/blob/master/.travis.yml

--
/Jacob Carlborg