- I am also not sure if the maintainers of gcc will want this ci, but many
other developers will be happy about that.
  Because many copies of gcc are already fork on github. We can see it
here: https://github.com/gcc-mirror/gcc.
  Also gcc maintainers are requested to check and validate the gcc as I did
in the CI here:
  https://gcc.gnu.org/contribute.html. They ask to test it on one platform
and run all testsuites.
  The CI can be extended to work not one job on linux, but other os as
windows and osx as well, then also more platforms on one click check.
- Github is not the main repo for gcc. github holds mirrors for gcc. Like
here: https://github.com/gcc-mirror/gcc.
   Many developers and forks are already on github.
- I am thinking this repo https://github.com/gcc-mirror/gcc is created by
the gcc maintainers because to do a mirror, you need to `git push --mirror`
from the
  original repo as they explain here:
https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository.
But maybe I
  am mistaken.
- It means each time a person will have a PR on their repo. the ci will be
activated. (In the mirror repo they turn the ci). Also the mirror will
allow it,
  It can activate the ci each time the master or the releases branches are
changed. github will handle it. It has already done it for all the other
open source projects.
  For public open source each job has time for 6 hours. can have unlimited
jobs as the repo wants. limited to 20 jobs in parallel. Also there is
unlimited time cpu. all free of charge.
  This is how github action does for all open source projects. meaning if
you just have an open repo (not private) you can have it.
- This should be fixed on the gcc side. If they do so, they will have a
great way to test their code, and have more free bug code to insert into
their repo.
  Also more devs can contribute and they can check gcc across platforms in
one single PR. They can run the ci on many OS systems that they don't have
access or skill to do.

They CI can extend to aarch64, also arm or any flavor. The ci of github
action supports public docker images, and can run gcc on them too.

Thank you for your support.

Regards,
Tal Regev.


On Wed, 12 Jul 2023 at 15:42, Christophe Lyon <christophe.lyon@linaro.org>
wrote:

> 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.
>>
>