<div dir="ltr"><div dir="ltr">Hi Tom,<div><br></div><div>First of: I'm a big fan of adding more automatic tests to find bugs. Great work!</div><div><br></div><div>On the other hand, I think we should consider creating some sort of test strategy for the LLVM project: </div><div><ul><li>What tests do we expect users to run before uploading patches?</li><li>What tests do we expect users to run before merging?</li><li>What tests do we run after merging?</li><li>What failures must be fixed, what failures can be ignored?</li><li>What do we check for on the build bots?</li><li>What do we check for on the release branches?</li><li>What do we check for on the pre-merge tests?</li><li>Which CI tools do we want to use (github, Jenkins, bulidbot, ...)?</li><li>What about running clang-tidy and clang-format?<br></li><li>What CMake configurations should we check? (Release/Debug, assertions, ...)</li><li>Do we want to run tests with Sanitizers?</li><li>Which of these systems do we expect users to monitor?</li></ul><div>I suppose it would be good to have a document that summarizes all of this so that we</div><div><ol><li>do not test the same thing twice and</li><li>do not miss any important checks.</li></ol><div>Does something like this exist? </div><div>Is anyone working on this?</div></div></div><div><br></div><div>Best,</div><div>Christian</div><div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 20, 2019 at 7:26 AM Tom Stellard 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Hi Tom,<br>
><br>
> This sounds very interesting! +1 from me.<br>
> What does this imply for the release testers?<br>
> Would it be possible / desirable for us to add self-hosted runners for<br>
> other architectures? I'm assuming GitHub only provides x86, right? I<br>
> totally missed any details about that in their docs, but it seems to<br>
> be implied here [1]. I'm not saying we should go all-possible-arches<br>
> from the start, we can definitely try it out only for x86 this time<br>
> around if you think that would be the best approach.<br>
><br>
<br>
Nothing changes for release testers at this point.  The main goal here is<br>
to get some post-commit testing so we can catch issues in the branch early.<br>
<br>
Longer term I think have self-hosted runners would be great, because it would<br>
allow us to fully automate the testing and uploading we do when a release gets<br>
tagged.<br>
<br>
You are correct that GitHub only provides x86 machines, however, they don't<br>
have enough disk space (14GB) to be able to run the test-release.sh script, so<br>
adding x86 self-hosted builders with more disk space would still be very useful.<br>
<br>
-Tom<br>
<br>
><br>
> [1] <a href="https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/" rel="noreferrer" target="_blank">https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/</a><br>
><br>
> Thanks,<br>
> Diana<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best,<div>Christian</div></div></div></div>