<div dir="auto">On the more general point of unrelated pre-merge failures. I've hit these a few times and also find them frustrating. Especially as a new contributor, it's really hard to know which checks are "ok to ignore". I find this even with things that are more like lint than full builds (e.g. clang-tidy). Having pre-merge checks is super valuable of course, but I think generally they should be less strict than post-submit.<div dir="auto"><br></div><div dir="auto">I'm not super familiar with the infra for these in particular, but I'm a bit surprised that this is a problem. Usually when setting up bots for my project I turn them on for post-submit before turning them on for pre-submit. Is there a reason that the infrastructure can't be shared here such that presubmit and postsubmit are basically just switches on the exact same build configuration? I gather that the phab integration adds a fair amount of complexity there. Would be a point in favor of using GitHub PRs I guess (although the review ux is definitely nicer on phab IMO)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 1, 2021, 13:54 Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 1, 2021 at 1:20 AM Nathan James via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Francesco,<br>
<br>
clang-tidy will run over all files in a patch, even if not supported in<br>
the build system, so errors about missing header files can often be<br>
ignored.<br>
<br>
As for the failing lit test, the are dependent on trunk having no build<br>
failures, which unfortunately isn't always the case. If the failing<br>
test doesn't appear to be related to the code you are working on in any<br>
way, it can (usually) be ignored.<br></blockquote><div><br></div><div>Unfortunately I believe that until we have a buildbot that is continuously building the main branch with the exact same configuration as the pre-merge, we'll keep having this issue of frequent unrelated failure. I've seen some tests being broken for days (and over a week) in the premerge configuration sometimes, likely because they don't have coverage on any of the post-commit bots.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
~Nathan<br>
<br>
On Sat, 2021-05-01 at 09:42 +0200, Francesco Bertolaccini via llvm-dev<br>
wrote:<br>
> Hi everyone,<br>
> this is the first patch I've submitted to LLVM, and I'm not well<br>
> acquainted with the automated scripts that are run as pre-merge<br>
> tests.<br>
> <br>
> I've been able to solve the formatting related issues, but there are<br>
> a<br>
> couple of tests that I'm not sure what to do about: clang-tidy warns<br>
> about missing header files, likely caused by the OCaml headers not<br>
> being<br>
> present on the machine running pre-tests, and a suggested fix in case<br>
> of<br>
> "unhelpful" clang-tidy warnings is to put the file into the<br>
> ignorelist.<br>
> I'm not sure this is the right course of action, because obviously<br>
> this<br>
> file has worked before without having to ignore it.<br>
> <br>
> Also, the 'lit.lit::test-output-micro.py' completely stumps me, it<br>
> doesn't seem to be related to what I'm patching and I can't really<br>
> understand its result.<br>
> <br>
> This is the link to phabricator for reference:<br>
> <a href="https://reviews.llvm.org/D101639" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D101639</a><br>
> <br>
> Thanks and best regards,<br>
> Francesco<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>