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:
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:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-September/thread.html)
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 bump).
3. Testing the release branches of gcc (releases/gcc-9,
releases/gcc-10, ...).
I am least bothered by having [1] 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.
Iain.
