Monorepo-wide CI checks should not trigger on projects that don't need them

[ldionne]

Libc++ does not use the monorepo-wide CI checks defined in premerge.yaml. However, these jobs still run on all LLVM pull requests, only to determine that there's nothing to do for libc++ and then be no-ops.

This creates noise and confusion when submitting PRs to LLVM projects that don't use these checks. Note that libc++ itself suffers from a similar problem: it imposes its BuiltKite pipeline checks on all LLVM monorepo PRs, which creates noise for all non-libc++ contributions. I am trying to address that in #165928.

Since we have a single monorepo for all of LLVM, I think it will be important going forward to ensure proper "insulation" between projects (when relevant) to avoid this.

[ldionne]

CC @boomanaiden154

[llvmbot]

@llvm/issue-subscribers-infrastructure

Author: Louis Dionne (ldionne)

Libc++ does not use the monorepo-wide CI checks defined in [premerge.yaml](https://github.com/llvm/llvm-project/blob/288ef04d2f19c5b0e4ce3cae450c63a365ab11e9/.github/workflows/premerge.yaml). However, these jobs still run on all LLVM pull requests, only to determine that there's nothing to do for libc++ and then be no-ops.

<img width="844" height="381" alt="Image" src="https://github.com/user-attachments/assets/223a5d7a-5d9f-452d-a393-eb471058ca98" />

<img width="1136" height="394" alt="Image" src="https://github.com/user-attachments/assets/6c0dc4a6-eb4a-4733-bf89-725a3843f22c" />

This creates noise and confusion when submitting PRs to LLVM projects that don't use these checks. Note that libc++ itself suffers from a similar problem: it imposes its BuiltKite pipeline checks on all LLVM monorepo PRs, which creates noise for all non-libc++ contributions. I am trying to address that in #165928.

Since we have a single monorepo for all of LLVM, I think it will be important going forward to ensure proper "insulation" between projects (when relevant) to avoid this.

[tstellar]

I'm not sure if this is going to be technically possible. I know in the past, that if you used the path filtering for triggering the tests, then you could not have them be 'required tests'. Not sure if this has changed, but we would need to test that first.

[boomanaiden154]

That's definitely still an issue.

An idea I've had for a while is to implement another job that is required that runs a python script (or equivalent) that waits on the status of other jobs based on the path/other criteria and returns a singular final status. That would let us have custom logic for all of this, but requires some infra work to do efficiently.

[tstellar]

@ldionne Is it OK if the test shows up on the list as 'skipped' or do you not want it to show up at all?

[ldionne]

The very best would be to not have anything (not even skipped) since it reduces noise, but I think it would be fine to have them marked as skipped.

Now that you mention the issue of "required tests", it rings a bell: I might have asked the same question on Discourse and got the same answer, and then forgot. Either way, we now have a Github issue to track it :)

Do I understand correctly that you care about having "required checks" because that's a requirement to enable the merge queue feature?

TLDR: It would be fine if we can have these workflows marked as skipped in our CI.

[tstellar]

@ldionne The "required checks" helps ensure people don't merge PRs with those tests failing (yes you can bypass this), but it's helpful for new contributors and helps long-time contributors from making mistakes.