This is an archive of the discontinued LLVM Phabricator instance.

[ci] Make libc++ and Clang CI scripts independent
ClosedPublic

Authored by ldionne on Jul 12 2023, 5:56 AM.

Details

Reviewers
philnik
Group Reviewers
Restricted Project
Restricted Project
Commits
rG298f207e0649: [ci] Make libc++ and Clang CI scripts independent
Summary

This simply moves existing CI-related scripts for Clang outside of libc++
to make the two projects independent with respect to CI.

The reason for making this change is that libc++'s CI pipeline history
was full of Clang runs, making it a lot harder to figure out information
about libc++'s own jobs. I created a pipeline for Clang and this patch
will run pre-commit CI for Clang inside that pipeline instead.

Diff Detail

Event Timeline

ldionne created this revision.Jul 12 2023, 5:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 12 2023, 5:56 AM
Herald added a subscriber: arichardson. · View Herald Transcript
ldionne requested review of this revision.Jul 12 2023, 5:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 12 2023, 5:56 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne updated this revision to Diff 539522.Jul 12 2023, 5:58 AM
ldionne edited the summary of this revision. (Show Details)

Update commit message.

ldionne added a reviewer: Restricted Project.Jul 12 2023, 5:59 AM
ldionne updated this revision to Diff 539524.Jul 12 2023, 6:03 AM

Try to fix path when generating the CI pipelines.

ldionne updated this revision to Diff 539526.Jul 12 2023, 6:08 AM

Touch a file inside Clang to test the triggering.

Herald added a project: Restricted Project. · View Herald TranscriptJul 12 2023, 6:08 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
ldionne updated this revision to Diff 539534.Jul 12 2023, 6:23 AM

Poke CI after fixing pipeline settings.

ldionne added a comment.EditedJul 12 2023, 6:37 AM

Ok, this is ready to go. More context around this change:

I created a clang-specific CI pipeline (https://buildkite.com/llvm-project/clang-ci) and Clang CI jobs will now trigger inside that pipeline instead of inside the libc++ pipeline (https://buildkite.com/llvm-project/libcxx-ci). The problem this solves is that 90% of the jobs of the libc++ CI pipelines are otherwise Clang jobs, which makes it nearly impossible for libc++ to figure out information about the jobs we're actually running.

  • For now, this does not have any impact on the fact that Clang CI is still utilizing libc++ resources (although this is next on my list of things to address).
  • This doesn't have any impact on whether we'll eventually want to move to Github Actions or some other CI system. This simply fixes the current system before the LLVM 17 release. In particular, I would like to avoid bikeshedding the location of the generate-buildkite-pipeline scripts under .ci -- it doesn't matter, I just wanted a neutral (non-libcxx-specific) location and that can be changed later once CI has stabilized.
ldionne updated this revision to Diff 539553.Jul 12 2023, 7:30 AM

Poke CI after fixing Clang CI pipeline clone URL.

philnik accepted this revision.Jul 12 2023, 7:46 AM
philnik added a subscriber: philnik.

I like this a lot! LGTM.

This revision is now accepted and ready to land.Jul 12 2023, 7:46 AM

Ok, this is ready to go. More context around this change:

I created a clang-specific CI pipeline (https://buildkite.com/llvm-project/clang-ci) and Clang CI jobs will now trigger inside that pipeline instead of inside the libc++ pipeline (https://buildkite.com/llvm-project/libcxx-ci). The problem this solves is that 90% of the jobs of the libc++ CI pipelines are otherwise Clang jobs, which makes it nearly impossible for libc++ to figure out information about the jobs we're actually running.

  • For now, this does not have any impact on the fact that Clang CI is still utilizing libc++ resources (although this is next on my list of things to address).
  • This doesn't have any impact on whether we'll eventually want to move to Github Actions or some other CI system. This simply fixes the current system before the LLVM 17 release. In particular, I would like to avoid bikeshedding the location of the generate-buildkite-pipeline scripts under .ci -- it doesn't matter, I just wanted a neutral (non-libcxx-specific) location and that can be changed later once CI has stabilized.

Please excuse my ignorance, but does this change precommit CI test coverage when reviews are created/updated? e.g., if a review goes up with changes only to Clang, will the review still get a libc++ test run to ensure the Clang changes don't break libc++?

Ok, this is ready to go. More context around this change:

I created a clang-specific CI pipeline (https://buildkite.com/llvm-project/clang-ci) and Clang CI jobs will now trigger inside that pipeline instead of inside the libc++ pipeline (https://buildkite.com/llvm-project/libcxx-ci). The problem this solves is that 90% of the jobs of the libc++ CI pipelines are otherwise Clang jobs, which makes it nearly impossible for libc++ to figure out information about the jobs we're actually running.

  • For now, this does not have any impact on the fact that Clang CI is still utilizing libc++ resources (although this is next on my list of things to address).
  • This doesn't have any impact on whether we'll eventually want to move to Github Actions or some other CI system. This simply fixes the current system before the LLVM 17 release. In particular, I would like to avoid bikeshedding the location of the generate-buildkite-pipeline scripts under .ci -- it doesn't matter, I just wanted a neutral (non-libcxx-specific) location and that can be changed later once CI has stabilized.

Please excuse my ignorance, but does this change precommit CI test coverage when reviews are created/updated? e.g., if a review goes up with changes only to Clang, will the review still get a libc++ test run to ensure the Clang changes don't break libc++?

It actually fixes it. Previously, if both libc++ and Clang were modified in a review, only the libc++ CI was triggered. After this patch:

  • If Clang is modified, the Clang pre-commit CI is triggered (which includes running the libc++ test suite w/ just-built clang in C++03, C++20 and Modules IIRC)
  • If Libc++ is modified, the libc++ pre-commit CI is triggered (which includes the 60ish jobs we have)
  • If both are modified, both are triggered.

I will land this because I can tell this is correct after following the CI pipeline's execution, and https://github.com/google/llvm-premerge-checks/pull/452 has already landed so the CI could start becoming red anytime now. If there are concerns about Clang having its own CI pipeline (which I think is only a huge improvement), please raise them and we can address that concern post-commit.

This revision was landed with ongoing or failed builds.Jul 12 2023, 11:02 AM
This revision was automatically updated to reflect the committed changes.

Thanks for working on this! I really like the direction. I mainly skimmed the code since the patch as already landed.

Ok, this is ready to go. More context around this change:

I created a clang-specific CI pipeline (https://buildkite.com/llvm-project/clang-ci) and Clang CI jobs will now trigger inside that pipeline instead of inside the libc++ pipeline (https://buildkite.com/llvm-project/libcxx-ci). The problem this solves is that 90% of the jobs of the libc++ CI pipelines are otherwise Clang jobs, which makes it nearly impossible for libc++ to figure out information about the jobs we're actually running.

  • For now, this does not have any impact on the fact that Clang CI is still utilizing libc++ resources (although this is next on my list of things to address).
  • This doesn't have any impact on whether we'll eventually want to move to Github Actions or some other CI system. This simply fixes the current system before the LLVM 17 release. In particular, I would like to avoid bikeshedding the location of the generate-buildkite-pipeline scripts under .ci -- it doesn't matter, I just wanted a neutral (non-libcxx-specific) location and that can be changed later once CI has stabilized.

Please excuse my ignorance, but does this change precommit CI test coverage when reviews are created/updated? e.g., if a review goes up with changes only to Clang, will the review still get a libc++ test run to ensure the Clang changes don't break libc++?

It actually fixes it. Previously, if both libc++ and Clang were modified in a review, only the libc++ CI was triggered. After this patch:

  • If Clang is modified, the Clang pre-commit CI is triggered (which includes running the libc++ test suite w/ just-built clang in C++03, C++20 and Modules IIRC)
  • If Libc++ is modified, the libc++ pre-commit CI is triggered (which includes the 60ish jobs we have)
  • If both are modified, both are triggered.

Thank you, this sounds great to me then! LGTM. :-)