GDC CI

[wjoe]

On Saturday, 5 September 2020 at 10:25:28 UTC, Johannes Pfau 
wrote:
> Am Sat, 05 Sep 2020 10:04:30 +0000 schrieb wjoe:
>
>> This thread is a continuation of the conversation "GDC 10.2.1 
>> Released" in the Announce group here [1]:
>> 
>
> To answer your other question:
>>> We use https://github.com/D-Programming-GDC/gcc for CI, but 
>>> commits will go to the GCC SVN first, so GCC SVN or snapshot 
>>> tarballs is the recommended way to get the latest GDC.
>>
>> Is this information still up to date ?
>> 
>> There's a semaphore folder. I suppose that's the one currently 
>> used with Semaphore CI. Is there something else ?
>
> 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 ?

How's upstream GCC doing CI ?