> In addition to being used for post-commit testing, having these CI definitions in the > main tree will make it easier for me (or anyone) to do pre-commit testing for the > release branch in a personal fork.
I find this part especially useful. I'm using these actions on a personal branch to validate patches on Linux, OSX and Windows, which gives me more confidence on its portability. On Thu, Nov 21, 2019 at 10:15 AM Christian Kühnel via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hi Tom, > > First of: I'm a big fan of adding more automatic tests to find bugs. Great > work! > > On the other hand, I think we should consider creating some sort of test > strategy for the LLVM project: > > - What tests do we expect users to run before uploading patches? > - What tests do we expect users to run before merging? > - What tests do we run after merging? > - What failures must be fixed, what failures can be ignored? > - What do we check for on the build bots? > - What do we check for on the release branches? > - What do we check for on the pre-merge tests? > - Which CI tools do we want to use (github, Jenkins, bulidbot, ...)? > - What about running clang-tidy and clang-format? > - What CMake configurations should we check? (Release/Debug, > assertions, ...) > - Do we want to run tests with Sanitizers? > - Which of these systems do we expect users to monitor? > > I suppose it would be good to have a document that summarizes all of this > so that we > > 1. do not test the same thing twice and > 2. do not miss any important checks. > > Does something like this exist? > Is anyone working on this? > > Best, > Christian > > On Wed, Nov 20, 2019 at 7:26 AM Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> > Hi Tom, >> > >> > This sounds very interesting! +1 from me. >> > What does this imply for the release testers? >> > Would it be possible / desirable for us to add self-hosted runners for >> > other architectures? I'm assuming GitHub only provides x86, right? I >> > totally missed any details about that in their docs, but it seems to >> > be implied here [1]. I'm not saying we should go all-possible-arches >> > from the start, we can definitely try it out only for x86 this time >> > around if you think that would be the best approach. >> > >> >> Nothing changes for release testers at this point. The main goal here is >> to get some post-commit testing so we can catch issues in the branch >> early. >> >> Longer term I think have self-hosted runners would be great, because it >> would >> allow us to fully automate the testing and uploading we do when a release >> gets >> tagged. >> >> You are correct that GitHub only provides x86 machines, however, they >> don't >> have enough disk space (14GB) to be able to run the test-release.sh >> script, so >> adding x86 self-hosted builders with more disk space would still be very >> useful. >> >> -Tom >> >> > >> > [1] >> https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/ >> > >> > Thanks, >> > Diana >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > -- > Best, > Christian > _______________________________________________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev