[libcxx-commits] [PATCH] D116891: [libc++][CI] Re-enable all CI jobs

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

In D116891#3258506 <https://reviews.llvm.org/D116891#3258506>, @philnik wrote:

> In D116891#3258420 <https://reviews.llvm.org/D116891#3258420>, @ldionne wrote:
>
>> In D116891#3256717 <https://reviews.llvm.org/D116891#3256717>, @philnik wrote:
>>
>>> Is there a reason this isn't landed yet? AFAIK the build nodes are back online.
>>
>> I love how fast the current reduced CI is, and I wanted to think about ways we can retain the same coverage and the same CI turnaround times.
>>
>> I'll check this in now and I can do that later. Basically, I think what I want is a slightly reduced matrix when reviews are uploaded, but the full matrix being run once every 4 hours (we already have a build that does that). Philosophically, what I'd prefer is the full matrix every time, but the hardware constraints we have are real, not philosophical, and the benefits of having quicker CI turnaround time are too.
>
> Couldn't we just add more pipeline steps? Most of the builds only fail in groups and only testing one of them would mean less resource usage. This would of course mean that the build could take longer if all the builds are green.
> I'd suggest something like
> Format, Generated output, Documentation -> C++2b, C++20, C++03, Modular build -> Windows, MacOS, Arm, AIX, No *, Debug iterators, Assertions, C++17, C++14, C++11 -> All the very resource intensive tests
> I probably forgot a few configs, but that should cover most of them. This would lead to less unnecessary resource usage while still having full test coverage.

The way I've approached this so far is by putting jobs with more "filtering power" first. I picked jobs that were usually giving us failures and put them first, basically. I think that makes sense because those provide the most signal.

I'd like to avoid adding more steps because, as you say, it makes the overall pipeline slower (although I agree that it would allow us to keep the same coverage without increasing resources). Instead, I think a good compromise is to slightly decrease our coverage for PR-time testing, but keep it at 100% for ongoing `main` testing.

For now I'll just restore what we had before to get back to 100% coverage all the time.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116891/new/

https://reviews.llvm.org/D116891