From: Christophe Lyon <christophe.lyon@linaro.org>
To: Martin Jambor <mjambor@suse.cz>
Cc: GCC Mailing List <gcc@gcc.gnu.org>,
Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
Subject: Re: Checks that autotools generated files were re-generated correctly
Date: Mon, 6 Nov 2023 18:19:15 +0100 [thread overview]
Message-ID: <CAPS5khY+i750qnXRuFxv3AY2xgaRLR7urNuBnbYJpv3Tka8ikg@mail.gmail.com> (raw)
In-Reply-To: <65491cda.c80a0220.5fa79.7688SMTPIN_ADDED_BROKEN@mx.google.com>
Hi!
On Mon, 6 Nov 2023 at 18:05, Martin Jambor <mjambor@suse.cz> wrote:
>
> Hello,
>
> I have inherited Martin Liška's buildbot script that checks that all
> sorts of autotools generated files, mainly configure scripts, were
> re-generated correctly when appropriate. While the checks are hopefully
> useful, they report issues surprisingly often and reporting them feels
> especially unproductive.
>
> Could such checks be added to our server side push hooks so that commits
> introducing these breakages would get refused automatically. While the
> check might be a bit expensive, it only needs to be run on files
> touching the generated files and/or the files these are generated from.
>
> Alternatively, Maxim, you seem to have an infrastructure that is capable
> of sending email. Would you consider adding the check to your buildbot
> instance and report issues automatically? The level of totally
After the discussions we had during Cauldron, I actually thought we
should add such a bot.
Initially I was thinking about adding this as a "precommit" check, to
make sure the autogenerated files were submitted correctly, but I
realized that the policy is actually not to send autogenerated files
as part of the patch (thus making pre-commit check impracticable in
such cases, unless we autogenerate those files after applying the
patch)
I understand you mean to run this as a post-commit bot, meaning we
would continue to "accept" broken commits, but now automatically send
a notification, asking for a prompt fix?
We can probably implement that, indeed. Is that the general agreement?
Thanks,
Christophe
> false-positives should be low (I thought zero but see
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635358.html).
>
> Thanks for any ideas which can lead to a mostly automated process.
>
> Martin
next parent reply other threads:[~2023-11-06 17:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <65491cda.c80a0220.5fa79.7688SMTPIN_ADDED_BROKEN@mx.google.com>
2023-11-06 17:19 ` Christophe Lyon [this message]
2023-11-07 7:38 ` Maxim Kuvyrkov
2023-11-07 13:50 ` Carlos O'Donell
2023-11-07 14:36 ` Martin Jambor
[not found] ` <654a4b60.2e0a0220.7f3b.6e5aSMTPIN_ADDED_BROKEN@mx.google.com>
2023-11-07 15:42 ` Christophe Lyon
2023-11-06 17:04 Martin Jambor
2023-11-07 22:13 ` Frank Ch. Eigler
2023-11-08 23:30 ` Mark Wielaard
2023-11-15 19:48 ` Mark Wielaard
2023-11-16 18:37 ` Martin Jambor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPS5khY+i750qnXRuFxv3AY2xgaRLR7urNuBnbYJpv3Tka8ikg@mail.gmail.com \
--to=christophe.lyon@linaro.org \
--cc=gcc@gcc.gnu.org \
--cc=maxim.kuvyrkov@linaro.org \
--cc=mjambor@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).