Switch coverage CI targets to EngFlow #39269
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently Envoy CI uses different RBE backends for different CI targets. EngFlow is one of available backends and we want to migrate most if not all targets to EngFlow. Other than just making the overall CI setup simpler, EngFlow appear to offer more powerful build grid machines at the moment, plus some additional nice features like automatically scaling memory when build tasks don't fit into available memory. One specific reason why I'd like to migrate coverage targets to EngFlow is because I want to switch them to static linking to workaround a bug in Clang/LLVM source-based coverage (see llvm/llvm-project#32849). With currently used Google RBE backend we are having issues with fuzzing coverage tests, as fuzzing tests include a lot of extensions and together with coverage instrumentation it pushes linker memory footrpint way to high and causing OOMs. Our approach to solving this particular problem is two-fold: 1. I want to migrate to EngFlow that can offer bigger machines (and it aligns with the general direction for Envoy CI to migrate to EngFlow. 2. I want to optimize our fuzzing targets a little bit by cutting out some unnecessary bits and reducing the number of libraries that linker need to link together (on top of reducing the amount of time it takes to build things and similar benefits). This particular PR takes care of the first part. Signed-off-by: Mikhail Krinkin <mkrinkin@microsoft.com>
phlax
reviewed
Apr 29, 2025
Signed-off-by: Mikhail Krinkin <mkrinkin@microsoft.com>
phlax
approved these changes
Apr 30, 2025
krinkinmu
added a commit
to krinkinmu/envoy
that referenced
this pull request
May 1, 2025
This reverts commit e0420ee. It unexpectedly resulted in lower coverage numbers - we should rollback while we are investigating what's going on to avoid disruptions.
krinkinmu
added a commit
to krinkinmu/envoy
that referenced
this pull request
May 1, 2025
This reverts commit e0420ee. It unexpectedly resulted in lower coverage numbers - we should rollback while we are investigating what's going on to avoid disruptions. Signed-off-by: Mikhail Krinkin <mkrinkin@microsoft.com>
phlax
pushed a commit
that referenced
this pull request
May 1, 2025
Commit Message: This reverts commit e0420ee. It unexpectedly resulted in lower coverage numbers - we should rollback while we are investigating what's going on to avoid disruptions. Additional Description: Some relevant discussions can be found in #39030 which prompted me to work on this in the first place. And I will use #39248 as a tracking bug for the coverage changes. Signed-off-by: Mikhail Krinkin <mkrinkin@microsoft.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Commit Message:
Currently Envoy CI uses different RBE backends for different CI targets. EngFlow is one of available backends and we want to migrate most if not all targets to EngFlow.
Other than just making the overall CI setup simpler, EngFlow appear to offer more powerful build grid machines at the moment, plus some additional nice features like automatically scaling memory when build tasks don't fit into available memory.
One specific reason why I'd like to migrate coverage targets to EngFlow is because I want to switch them to static linking to workaround a bug in Clang/LLVM source-based coverage (see llvm/llvm-project#32849).
With currently used Google RBE backend we are having issues with fuzzing coverage tests, as fuzzing tests include a lot of extensions and together with coverage instrumentation it pushes linker memory footrpint way to high and causing OOMs.
Our approach to solving this particular problem is two-fold:
This particular PR takes care of the first part.
Additional Description:
Some relevant discussions can be found in #39030 which prompted me to work on this in the first place. And I will use #39248 as a tracking bug for the coverage changes.
Risk Level: medium (it could break CI and cause disruption, but rolling it back should be easy)
Testing: I applied the same change in the envoy-ci-staging repo and created a test PR to see if EngFlow is used for coverage. The setup between envoy-ci-staging and envoy repo is not exactly the same, so I could have missed something.
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a
+cc @phlax