GDC CI

[Iain Buclaw]

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:
>> Am Sat, 05 Sep 2020 10:04:30 +0000 schrieb wjoe:
>>
>>> [...]
>>
>> To answer your other question:
>>> [...]
>>
>> That information is probably quite obsolete: As GCC upstream 
>> uses git now, it might be possible to simplify the overall 
>> process. That proces never really worked out and was quite 
>> complicated anyway, as it required committers to locally merge 
>> the commit containing the .semaphore configuration files 
>> before pushing to github. In hindsight, it was probably a bad 
>> idea.
>>
>> 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.
>>
>> So that's why the old approach required merging a commit which 
>> includes the CI configuration. Maybe a better way is to 
>> automatically generate a new commit including CI configuration 
>> for each commit to be tested. This could probably be done with 
>> buildkite? Then trigger new build jobs for that auto-generated 
>> commit. The main difficulty there is integrating this into a 
>> somewhat nice workflow / interface.
>
> Please forgive my confusion.
>
> There are 2 repositories, upstream GCC and 
> GitHub/D-Programming-GDC/gcc.
> The former isn't hosted on GitHub but on gnu.org.
> The latter is necessary for CI, because reasons, and is a 
> mirror of the upstream git repository.
> Development is done in the upstream repository.
> Because of that we can't put our CI configs into the project 
> root.
> Thus the GitHub mirror is required for those CI providers that 
> don't support a custom configuration location.
> But it could be done with the upstream repo otherwise, unless 
> the CI service only works with projects hosted on GitHub - 
> Cirrus CI for instance.
>
> Is that correct ?
>

That sounds about right.

The only way you'd be able to test the upstream GCC repository 
directly is by doing periodic builds, rather than builds based 
off triggers.  The CI logic would have to live in a separate 
repository.  For convenience, this would be on GitHub.


> 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)