Case Study
About Envoy Mobile
The open-source project Envoy is a network proxy that can improve the observability of complex networking setups, as typically present in modern cloud-native applications. This large C++ application is a member of the CNCF, with contributions from 400+ companies and 4k+ individuals.
Envoy Mobile is a subrepo of Envoy that targets mobile development. Its client networking libraries bring the power of Envoy to mobile systems.
Mobile builds and tests bring their own set of challenges:
- They need to target several operating systems (e.g. Android, iOS),
- may be bound to certain host operating systems (e.g. iOS apps need to build on MacOS), and
- use a variety of programming languages (Java/Kotlin, C++, Python, ObjC, Swift).
This heterogeneity led to particularly slow builds and tests and made Envoy Mobile the perfect candidate to migrate to EngFlow Remote Execution.
6x
Migrating to remote execution
Migrating a Bazel project to remote execution can be a daunting task. For instance, a Bazel user may be tempted to:
- mark a Bazel rule in a BUILD file as local in order to escape Bazel’s sandboxing,
- use custom scripts (e.g github.com/actions/setup-java) to set up locally installed tools via hard-coded paths instead of using Bazel toolchains,
- blindly rely on Bazel’s capacity to detect local tools (e.g. by not declaring dependencies in BUILD files),
- rely on certain Bazel features that may not work remotely (e.g. coverage may break),
- rely on local tools that are not available on the docker image running the action (e.g. thread sanitization may need special docker capabilities, missing header files),
- and more.
These are common issues that tend to require a certain level of Bazel expertise to overcome. EngFlow can advise with this migration, or take care of it completely.
6x faster builds and tests with EngFlow
EngFlow’s Bazel experts migrated Envoy Mobile’s presubmit flows to remote execution and manage an EngFlow Remote Execution cluster for them. The overall build and test time is now ~20 minutes, compared to ~2 hours before. This speed-up of ~6x has led to a much faster turnaround time of their open-source contributions.
The table below contains a detailed breakdown of the migration’s pull requests, as well as the achieved speed-ups based on the programming language of the source code, the host OS (the OS of the machine running Bazel), and the target OS (the OS of the machine running the final artifacts).
Pull requests | Speed-up | Language | Host OS | Target OS |
---|---|---|---|---|
#1697 | 4x | ObjC / Swift | MacOS | iOS |
#1697 | 10x | C++ | Linux | Linux |
#1705, #1821, #1838 | 5–10x | Java / Kotlin | MacOS | Android |
#1707 | 3x | C++ | MacOS | MacOS |
#1745, #1781 | 5x | C++ (ASAN/TSAN) | Linux | Linux |
#1753 | 10x | Python | Linux | Linux |
#1757 | 6x | C++ (LLVM coverage) | Linux | Linux |
#1759 | 2x | Kotlin | MacOS | MacOS |
#1801 | 10x | Java / Kotlin | Linux | Android |
Sharing build and test results
Additionally, EngFlow Build and Test UI allows contributors to share their build and test results and drill down on them.