GDC CI

[wjoe]

On Monday, 7 September 2020 at 09:14:08 UTC, Iain Buclaw wrote:
> On Saturday, 5 September 2020 at 21:14:28 UTC, Iain Buclaw 
> wrote:
>> On Saturday, 5 September 2020 at 11:23:09 UTC, wjoe wrote:
>>> On Saturday, 5 September 2020 at 10:25:28 UTC, Johannes Pfau 
>>> wrote:
>>>>
>>>> The main difficulty in setting up CI for GDC is that we 
>>>> can't simply put CI configuration files in the toplevel 
>>>> folder, as that folder is under GCC's control. For CI which 
>>>> allows you to keep the configuration out of the 
>>>> repositories, this is not a problem. But for those requiring 
>>>> certain files in the top-level folder, it's more complicated.
>>>>
>>> How's upstream GCC doing CI ?
>>
>> They aren't.  Or rather, other people are building every so 
>> often, or have their own scripts that build every single 
>> commit, and then post test results on the mailing list (i.e: 
>> https://gcc.gnu.org/pipermail/gcc-testresults/2020-September/thread.html)
>
> So when it comes to CI, there are two/three use cases that need 
> to be considered.
>
> 1. Testing a changes to D or libphobos prior to committing to 
> gcc mainline/branch.
>
> 2. Testing the mainline (master) branch, either periodically, 
> every commit, or after a specific commit (such as the daily 
> bump).
>
> 3. Testing the release branches of gcc (releases/gcc-9, 
> releases/gcc-10, ...).
>
> I am least bothered by having [1] covered.  I have enough faith 
> that people who send patches have at least done some level of 
> due diligence of testing their changes prior to submitting.  So 
> I think the focus should only be on the frequent testing of 
> mainline, and infrequent testing of release branches.
>
> If Cirrus has built-in periodic scheduling (without the need 
> for config files, or hooks added to the git repository), and 
> you can point it to GCC's git (or the GitHub git-mirror/gcc) 
> then that could be fine.  CI scripts still need to live in a 
> separate repository pulled in with the build.
>
> Iain.

Cirrus CI currently only supports GitHub projects. Therefore the 
Dockerfile needs to be hosted there. But nowhere it says that you 
can't clone any arbitrary repository via a setup script.

Options I can think of are:
A) A Dockerfile for each case in (1.,) 2. and 3., or
B) A docker container which provides the environment to build GCC 
and a (Cirrus) CI config which defines the tasks to cover (1.,) 
2. and 3.

A) sounds like a lot of duplication so I'm in favor of B)

Cirrus CI also provides a Docker Builder VM which can build and 
publish docker containers.