[lldb-dev] [llvm-dev] [Openmp-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
Serge Guelton via lldb-dev
lldb-dev at lists.llvm.org
Thu Nov 21 04:02:34 PST 2019
> 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
> 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-dev at lists.llvm.org> wrote:
> Hi Tom,
> First of: I'm a big fan of adding more automatic tests to find bugs. Great
> 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?
> On Wed, Nov 20, 2019 at 7:26 AM Tom Stellard via llvm-dev <
> llvm-dev at 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 . 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
>> Longer term I think have self-hosted runners would be great, because it
>> allow us to fully automate the testing and uploading we do when a release
>> You are correct that GitHub only provides x86 machines, however, they
>> 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
>> > 
>> > Thanks,
>> > Diana
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev