ibuclaw at gdcproject.org
Mon Sep 7 09:14:08 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
>>> 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:
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
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,
I am least bothered by having  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.
More information about the D.gnu