On Saturday, 5 September 2020 at 10:25:28 UTC, Johannes Pfau
wrote:
Am Sat, 05 Sep 2020 10:04:30 +0000 schrieb wjoe:
This thread is a continuation of the conversation "GDC 10.2.1
Released" in the Announce group here [1]:
To answer your other question:
We use https://github.com/D-Programming-GDC/gcc for CI, but
commits will go to the GCC SVN first, so GCC SVN or snapshot
tarballs is the recommended way to get the latest GDC.
Is this information still up to date ?
There's a semaphore folder. I suppose that's the one currently
used with Semaphore CI. Is there something else ?
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 ?
How's upstream GCC doing CI ?
