GDC CI

[Iain Buclaw]

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.