[clang] [llvm] [clang][ci] Move libc++ testing into the main PR pipeline (PR #93318)

[Vlad Serebrennikov via cfe-commits]

================
@@ -54,3 +54,68 @@ cmake -S "${MONOREPO_ROOT}"/llvm -B "${BUILD_DIR}" \
 echo "--- ninja"
 # Targets are not escaped as they are passed as separate arguments.
 ninja -C "${BUILD_DIR}" -k 0 ${targets}
+
----------------
Endilll wrote:

> 1. It's not parallelized anymore

Performance that we get from parallelization only helps when there's low amount of PRs to test to begin with (so we have idle agents). This is not the case we need to focus on at the moment

> 2. If one job fails, you don't get signal from whether the other jobs would fail too

Sure, but I consider it minor. Nothing stop us from iterating on this later.

> 3. The reporting on Github is going to be confusing because everything will be under the same job

Entirety of the reporting for Clang PRs has been single `buildkite/github-pull-requests` entry, and even with the very recent change that enabled per-job reporting, libc++ jobs haven't been reported. So this patch doesn't regress anything for Clang contributors. We still have the primary piece of information whether the CI passed or not. Again, we can iterate on this later.

> 4. This doesn't scale if we want to add more testing to be done against the just-built Clang

Additional Clang testing has scaling problems either way, because as I mentioned earlier, splitting jobs only helps when there are free agents to begin with.

> Instead, I would suggest changing generate-buildkite-pipeline so that it adds additional steps to the pipeline when we're testing Clang. These steps can communicate via artifacts uploading/downloading like they used to.

If you're willing to do the work in a reasonable time (remember we're reducing CI pressure here), you can take over this PR or I can abandon it. I personally had enough of bash scripting to iterate on this immediately.

https://github.com/llvm/llvm-project/pull/93318