August 2022 Summaries

The release of rules_js 1.0.0 marks a significant improvement in integrating JavaScript tooling with Bazel, particularly benefiting Angular applications. The Angular CLI provides a comprehensive developer experience by wrapping around the Angular Architect library, allowing various tools like webpack and Sass integration to function seamlessly. However, while the Angular Architect offers an all-in-one approach, it isn't perfectly suited for Bazel's style, which thrives on splitting tasks into independent, cacheable actions. By using Angular's ngc compiler with Bazel, developers can leverage Bazel's advantages like parallelization and remote execution. This setup involves using Bazel's macros to declare ngc as the compiler and configure various Angular project aspects like TypeScript, HTML, and CSS using custom macros. Overall, while Angular Architect simplifies the process, Bazel's approach offers the benefits of modular and efficient build systems, allowing for independent compilation and customization of tools such as webpack for bundling.

Memory management poses significant challenges in cloud-hosted build systems, particularly when using Bazel, a build tool that can encounter two main memory issues: the Bazel server's JVM exceeding its heap size and the system running out of memory due to subprocess actions consuming resources. The Bazel server might exit with code 33 if it runs out of memory, a situation that can be mitigated by adjusting JVM parameters or using memory profiling tools to identify excessive memory consumption. Additionally, concurrent actions scheduled by Bazel can deplete system memory, especially if Bazel misjudges available resources or the memory needs of each action. Remedies include adjusting the --local_ram_resources flag to align with container limits, reducing concurrency with the --jobs flag, and utilizing attributes like test_size to allocate adequate resources for specific tasks. Remote Build Execution offers an alternative by offloading intensive tasks to a cloud environment, potentially alleviating local resource constraints.

Bazel, often perceived as a hermetic build system, faces challenges with C/C++ built-in rules due to their non-hermetic nature, affecting reproducibility and portability. This issue arises because C++ toolchains traditionally depend on host system libraries for compiling and linking, which can lead to discrepancies across different machines and environments. To address this, developers can utilize a "sysroot" to ensure a consistent set of libraries, promoting uniformity in builds. The sysroot approach allows for deterministic outputs that are reproducible across various systems by linking against specific versions of libraries like libstdc++.so, thereby minimizing discrepancies caused by version skew. Portability is enhanced by using runtime search paths to link against stable system libraries, such as libc, while including older versions of libraries like glibc in the sysroot to ensure compatibility across different runtime environments. Static linking, although an option, can lead to larger binaries and potential compatibility issues, particularly with libraries like glibc and libstdc++, which are typically dynamically linked due to their extensive use of runtime-loaded shared objects. Consequently, while static linking can be beneficial for performance, shared linking is often preferred unless specific scenarios justify the trade-offs.

The text discusses the advantages and challenges of implementing a monorepo structure for code management, emphasizing the importance of integrating "mono-CI/CD" practices to maintain consistency and efficiency. It highlights the concept of a "shared green" model, where a single build and test pipeline is used across all projects in the repository, ensuring that nothing can be released if any part of the code is failing. The role of a "Build Cop" is crucial in maintaining a green status by quickly addressing breakages and having the authority to revert problematic commits. The text also addresses the complexities of managing continuous integration and delivery (CI/CD) in large organizations, noting that systems like Google's SkyFrame can be occasionally incorrect while smaller companies might manage better with a shared green approach. It suggests strategies to minimize downtime and improve responsiveness, such as reducing the time between detection and repair of issues and empowering on-call staff to make necessary corrections. Additionally, it explores the use of Merge Queues to handle frequent in-flight semantic collisions, providing examples from companies like Google and Uber to illustrate the viability of these practices at different scales.

rules_js has reached its first major release, offering a faster and more compatible integration of JavaScript build, test, and release tools with Bazel, marking an advancement over the prior rules_nodejs. Released under an Apache 2.0 license by Aspect Development, a Bazel consulting agency, this open-source project has seen contributions from engineers at companies like Figma, Aurora, Robinhood, and Adobe, although no large company funds its development. Users are encouraged to support the project financially through various means such as booking paid support meetings with lead engineers, paying for specific open-source software fixes, or hiring Bazel experts as consultants. Aspect Development emphasizes community involvement and offers different options for organizations to engage with and benefit from their expertise in Bazel, inviting partnerships to explore the potential of rules_js in building robust projects.