[CFARM] Script for automatic checking of patches

[Manuel López-Ibáñez]

On 02/07/07, Sebastian Pop <sebpop@gmail.com> wrote:
> Hi,
>
> Here is a script that is automating the build and test of a gcc tree.
[snip]

I have a similar script, a bit more complex, based on
contrib/gcc_build. It uses a file as a queue of patch filenames that
must be tested. Maybe you can steal some ideas from my script (I think
yours is much simpler and clearer, tough).

For example, it is much more reliable to use the following to cleanup
the source directory:
    svn cleanup && svn revert -R . && svn st | cut -d' ' -f5- | xargs rm -v

> For the moment it is not possible to send emails from the compile
> farm, but the functionality should work if a sendmail is set up.  My
> intent is to allow other users of the cfarm to scp their patches to
> this auto-tester patches directory.

I can send mails from the compile farm perfectly. I have been doing
that since a long time ago.

> I'm still quite annoyed by the fact that when new fails are inserted
> in trunk, there is no way to filter out these new fails from the fails
> due to the tested patch.  One possible solution is to schedule every
> now and then a bootstrap of a pristine tree to reset the set of
> passing tests, but this can be done outside the tester.
>

I think your script should test a pristine tree and then compare with
the results of the patched tree. I think it is a bad idea to "svn
update" for every patch. It can be a bit more clever about the
revision required by the patch. You could store test results for many
pristine revisions and you could update only if the current revision
is older than the one required by the patch.

> I also would like to include this script in gcc/contrib.  Okay for trunk?

If you include it in gcc/contrib, why not make use of gcc_update and
compare_tests? I have the feeling that there is a lot of duplicated
functionality there. But still, perfect is the enemy of good, so I am
in favour of including it in contrib.

Other suggestions: "ls -rt -1" and use the same technique as
gcc_update to self-update the script.

Cheers,

Manuel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gccfarming
Type: application/octet-stream
Size: 14173 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070703/973ff6fc/attachment.obj>