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:
[...]
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.
Periodic builds sound like what Cirrus CI calls cron builds.
But if the repository needs to be forked for CI it's kind of
periodic as well if the commits are only merged in periodically.
Currently I'm looking into building a docker container which can
run a GDC build. Because Cirrus CI supports Dockerfile/s directly
and every other CI seems to run its tasks/jobs inside of a docker
container this seems like a viable approach and can be extended
with the ARM targets mentioned in your item number 3.
