invalid at example.com
Mon Sep 7 10:41:50 UTC 2020
On Monday, 7 September 2020 at 09:14:08 UTC, Iain Buclaw wrote:
> On Saturday, 5 September 2020 at 21:14:28 UTC, 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
>>>> 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 mainline/branch.
> 2. Testing the mainline (master) branch, either periodically,
> every commit, or after a specific commit (such as the daily
> 3. Testing the release branches of gcc (releases/gcc-9,
> releases/gcc-10, ...).
> 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.
Cirrus CI currently only supports GitHub projects. Therefore the
Dockerfile needs to be hosted there. But nowhere it says that you
can't clone any arbitrary repository via a setup script.
Options I can think of are:
A) A Dockerfile for each case in (1.,) 2. and 3., or
B) A docker container which provides the environment to build GCC
and a (Cirrus) CI config which defines the tasks to cover (1.,)
2. and 3.
A) sounds like a lot of duplication so I'm in favor of B)
Cirrus CI also provides a Docker Builder VM which can build and
publish docker containers.
More information about the D.gnu