This essentially reverts commit 89f4a18f371d8 now that our CI is back
online at full capacity.
Details
Details
- Reviewers
- None
- Group Reviewers
Restricted Project - Commits
- rG1f6af9c9cefd: [libc++][CI] Re-enable all CI jobs
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
I'm going to ship this without the Bootstrapping build, and then handle the Bootstrapping build separately. I'd like to avoid other jobs regressing in the meantime.