Hi,


On Sun, 9 Jul 2023 at 19:13, Tal Regev via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> Description: adding a ci in a github repo. Everytime a user will do a PR to
> master branch or releases branches, it will activate the ci on their repo.
> for example: https://github.com/talregev/gcc/pull/1. Can help users to
> verify their own changes before submitting a patch.
>
> ChangeLog: Add a linux CI
>
> Bootstrapping and testing: I tested it on linux with
> host: x86_64-linux-gnu
> target: x86_64-linux-gnu
> some tests are failing. You can see the results in my CI yourself.
>
>
Thanks for sharing your patch & idea.
I think GCC validation is and has been a problem for a long time ;-)

I am not a maintainer, so take my comments with a grain of salt ;-)

- I don't know if the GCC project would want to accept such patches,
pointing to github etc...
- github is not the main GCC repository, it hosts several mirrors AFAIK
- these mirrors are updated by individuals, I think, I don't know at which
frequency etc... correct me if I'm wrong
- would this mean that each time each such mirror/fork is updated, this
triggers builds on github servers? Would that handle the load? I don't
think so (also: how many "free" minutes of CPU time can be used?)
- as you have noticed the GCC testsuite is not 100% clean (i.e. there are
failures, so 'make check' always exits with an error code), making such a
step useless. What we need is to compare to a baseline (eg. results of
previous build) and report if there were detections. Several companies have
CI systems doing this (either internally, or on publicly accessible servers)

In particular, at Linaro we monitor regressions for several arm and aarch64
flavors, and we are also experimenting with "pre-commit CI", based on
patchwork.

Thanks anyway for sharing, it's good to see such initiatives ;-)

Christophe



> Patch: attach to this email.
>