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:
Am Sat, 05 Sep 2020 10:04:30 +0000 schrieb wjoe:
[...]
To answer your other question:
[...]
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 ?
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.
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)
