GDC CI
wjoe
invalid at example.com
Sun Sep 6 21:52:04 UTC 2020
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:
>>> [...]
>>
>> 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.
Periodic builds sound like what Cirrus CI calls cron builds.
But if the repository needs to be forked for CI it's kind of
periodic as well if the commits are only merged in periodically.
Currently I'm looking into building a docker container which can
run a GDC build. Because Cirrus CI supports Dockerfile/s directly
and every other CI seems to run its tasks/jobs inside of a docker
container this seems like a viable approach and can be extended
with the ARM targets mentioned in your item number 3.
More information about the D.gnu
mailing list