Gerrit Code Review 3.13 has landed, bringing a significant wave of security enhancements, powerful automation, and next-generation AI features designed to streamline your development workflow. This release reflects a healthy, growing open-source project, with a focus on improving both the user experience and the underlying security and configurability of the platform.
Here are the top 6 features and improvements you need to know about in Gerrit 3.13:
Introducing Gerrit Flows for Powerful Automation
Gerrit Flows is a game-changing new concept that introduces automation rules for changes. It is a powerful generalization of the logic previously found in issue tracker plugins (like its-jira), allowing you to define a sequence of actions triggered when specific conditions are met.
This is a pluggable service, meaning that while the core functionality is in Gerrit, community plugins can easily integrate it with systems like Jira, GitHub Issues, or internal tools.
An example could be to add reviewers only after the CI/CD has validated the change, so that the reviewer doesn’t waste time reviewing a change that will ultimately receive a minus one from the build process.
HTTP Auth-Tokens Replace Long-Lived Passwords
In a major security upgrade driven primarily by SAP’s contribution, Gerrit 3.13 deprecates long-lived HTTP passwords in favor of secure, time-limited Authentication Tokens (Auth-Tokens).
This enhancement addresses two long-standing security concerns with previous HTTP passwords:
Expiration: Tokens can now be set to expire, allowing organizations to enforce rotation policies that were previously not enforceable when using Git or the Gerrit REST API over HTTPS.
Multiple Credentials: Users can have more than one token with friendly names, enabling proper credential rotation (like blue/green deployment) for automated scripts without downtime.
Tokens are a full replacement of the legacy HTTP passwords, as the ability to define their maximum lifetime is often a prerequisite for security compliance. Generating a new token credential would automatically remove the deprecated passwords stored in the account’s profile.
Next-Gen AI Assistance: AI prompt generation for Code Review
Gerrit 3.13 firmly steps into the era of AI-assisted development by enabling its foundational AI features by default and introducing native facilities to request help to review incoming changes using an external LLM.
AI-Assisted “Generate Prompt” Feature: This feature was previously released as an experiment and is now enabled by default. It helps users generate rich, explicitly crafted prompts for LLMs (such as Gemini, ChatGPT, or Claude) to assist with code reviews. Users can ask for help with the commit message, request improvements, or check for security concerns.
Dedicated UI for Project Labels and Submit Requirements
Configuration and administration are significantly simplified with the introduction of dedicated UI panels for managing Project Labels and Submit Requirements.
Interactive Project Configuration vs. config file editing: Previously, defining these project settings required cloning and editing the project.config file, either offline or online, a process described as difficult and error-prone for most users.
Submittability Split: This reinforces the modern split where Labels are just votes, and Submit Requirements formally define the logic for a change’s submittability.
End-to-End Group Deletion \o/
This was a long-awaited quality-of-life feature: Gerrit 3.13 provides full end-to-end functionality to delete internal groups directly through the UI and a dedicated REST API.
Administrative Control: In the past, groups, once created, were permanent. Now, administrators can remove them.
Prerequisite: A group cannot be deleted if it is referenced in any ACL (access control list). Admins must first reshape their ACLs before removal. The community has acknowledged that the resulting error message needs improvement to show where the group is referenced.
Significant UI/UX Updates, Including Drag-and-Drop
Gerrit continues its modernization effort, focusing on a cleaner, more efficient user experience, thanks largely to contributions from Paladox/Wikimedia.
Drag-and-Drop Reviewers: Users can now drag and drop reviewers and CCed users to move them between fields, eliminating the annoying multi-step process of removing a user from one list and adding them to the other.
Mobile and Material Updates: The release includes extensive modernization, replacing older components with @material/web, and a redesigned mobile UI for improved navigation.
Gerrit 3.13 By The Numbers
A Community Effort Gerrit 3.13 saw a significant push in core development, reversing the trend of previous releases that focused more heavily on plugins. The number of commits in Core Gerrit went from ~600 in Gerrit 3.12 to over 900 in Gerrit 3.13, showcasing an amazing increase of pace in the development speed of the project, which is great to see.
The open-source health of Gerrit is strong, with no single organization contributing over 50% of the changes. The contributions are spread across many companies, demonstrating the actual value of open source and the good health of the project. Google continues to lead the project from the forefront with almost 40% of commits.
GerritForge’s Contribution
Here at GerritForge, led by maintainer Luca Milanesio, we contributed 28% of the commits to the past 12 months of the Gerrit project contributions! We also, as usual, performed the crucial work required to take the finished code and turn it into a consumable release for the world, including, but not limited to, managing the whole release process and continuing to host the CI/CD pipelines for the project.
This dedicated effort ensures the smooth, professional delivery of every new version of Gerrit.
However, the world it was built for – local repositories and teams, along with simple, human-centric CI/CD pipelines – no longer exists.
Today, codebases are massive. Teams are global. And AI is generating code faster than ever before. Our infrastructure hasn’t kept pace, and traditional Git servers are reaching their limits.
Development Has Outgrown Traditional Git
Software development has exploded in both volume and velocity. According to Archive Market Research, the global software repository market will hit $15 billion in revenue in 2025, growing at 15% annually through 2033. GitHub now hosts over 420 million repositories, supporting more than 100 million developers – each pushing more commits, more frequently, and with more automation than ever.
At the same time, 97% of teams now use AI-assisted tools for vibe-coding, AI-agents for creating PRs and commits, automated AI-code-review, and AI-generated documentation. This results in a massive surge in server traffic, particularly read operations from increased test jobs and automated quality-checking processes, which are literally exploding.
Traditional scaling methods – adding more servers, bigger instances, or wider clusters – simply don’t address the core issue: the world has changed since Git was built 20 years ago.
The Breaking Point for Traditional Git Servers
The symptoms are now familiar to most engineering teams:
Slow performance. Git clones and fetches are taking several minutes or even timing out instead of completing swiftly in a few seconds.
Pipeline delays. CI/CD is waiting for repositories to be available for cloning or fetching, which delays the feedback cycle.
Storage capacity strain. Larger monorepos or multi-repo setups are hitting massive BLOB count and hitting ref limits. When storage is hosted on the Cloud or on shared disks, the increase in the directories and I/O transfer makes Git almost unusable.
Rising costs. Over-provisioned infrastructure is trying (and failing) to keep up. The provisional or elastic filesystem limits increase significantly, bringing operational costs to new heights never seen before, and putting more pressure on the budget.
The Archive Market Research report warns: “The rising complexity of software development necessitates efficient and reliable repositories for managing code, dependencies, and artifacts.”
In other words, the systems we depend on to deliver software are now slowing software down.
Scaling Smarter, Not Harder
At GerritForge, we believe that simply throwing more hardware at the problem is no longer enough: it is Git and its utilisation that need to be smarter. We have been researching on the use of AI for optimising the performance and scalability of repositories for over 3 years and shared our findings with the global scientific community.
That’s why we built GHS, an AI-powered accelerator for Git-based SCMs.
We have simulated and demonstrated how traditional tools would collapse and developed GHS, a brand-new model to overcome the traditional limitations of the Git repositories.
GHS learns how your repositories behave, your access patterns, your CI/CD workflows, and your traffic peaks – and, using reinforcement learning, automatically optimises performance in real-time.
With GHS, the whole development team will experience:
Up to 100× faster Git operations. Clones and fetches keep on completing at raw speed, without slowdowns, timeouts or slack.
Real-time auto-optimisation. The Git repositories are automatically monitored and optimised for speed, without manual operations.
Lower operational costs. The CPU and storage do not suffer from the overload of incoming traffic, delivering better performance on existing hardware. There is no need to scale up the infrastructure and costs massively.
Increased reliability. Git servers remain stable even under extreme load, eliminating the need for emergency restarts or maintenance.
Traditional scaling adds more servers. GHS scales using its sophisticated AI model to get the most out of what you already have.
The Gerrit User Summit 2025 made one thing clear: the era of traditional scaling is coming to an end.
As repositories grow and workflows evolve, the next generation of developer infrastructure must be intelligent, simplified & resilient. AI isn’t replacing developers – it’s augmenting them. But if your Git infrastructure can’t keep pace with this new level of activity, your entire SDLC pipeline will suffer.
2025 marks a turning point for software delivery. Traditional Git servers can’t keep up, but that doesn’t mean your team can’t. Because in modern DevOps, speed isn’t just efficiency, it’s a competitive edge.
The Gerrit Code Review Open-Source project has transitioned from using Google Cloud Platform’s Remote Build Execution (RBE) to BuildBuddy’s on-premises to address performance, stability, and latency issues. The migration process included setting up a new Jenkins controller and provisioning BuildBuddy executors on newly provisioned on-premises boxes, which showed significantly reduced build times and a more consistent and reliable performance. After thorough evaluation and community consensus, BuildBuddy was adopted as the new default for Gerrit’s CI/CD pipeline, enhancing overall efficiency and stability.
Historical Context
The Gerrit Code Review project has undergone significant evolution in its build processes to enhance efficiency and performance. This evolution reflects the increasing complexity and demands of modern CI/CD pipelines.
Overview of Gerrit Code Review
Gerrit is a powerful code review tool with a powerful web and command-line interface, all built on top of the Git open-source project. Gerrit codebase is significant and multifaceted, using Python tooling, TypeScript front-end and a Java-based backend. To appreciate the challenges and the need for robust build tools, consider the scope of Gerrit’s codebase and build activity:
Plugins: Gerrit comprises 14 core plugins maintained as git submodules, plus a universe of over 300 community-based plugins developed in multiple languages, from Java to Scala and Groovy.
Java Codebase: The project includes 6011 Java files, with 4765 dedicated to production code, amassing ca. 411,768 lines of code (LoC). Additionally, there are 1246 test files (924 unit tests and 322 integration tests) contributing another ca. 276,632 LoC.
Frontend Codebase: The frontend is built with 110 JavaScript files (ca. 2345 LoC), 733 TypeScript files (ca. 175,765 LoC), 293 HTML files, and 9 CSS files.
Dependencies: Gerrit relies on 135 Java dependencies managed through Maven and 25 NPM dependencies (5 runtime and 20 development).
Gerrit has been founded in 2008 and has over 15 years of code-history, which reflects the evolution of the build tools, Java VMs and front-end technologies used for over a decade. The pre-requisites that you would have to manage in order to build Gerrit are diverse and quite challenging.
Build and Verification Activity
The Gerrit project is highly active, with rigorous commit-level verification processes to ensure code quality and stability. For example, from June 9 to June 23, 2024, Gerrit handled:
Total of changes:
Branch
Number of changes
master
65
stable-3.10
18
stable-3.9
16
stable-3.8
15
stable-3.7
2
stable-3.6
0
stable-3.5
1
stable-3.4
1
Total
118
Total of revisions (patch sets):
Branch
Number of revisions
master
230
stable-3.10
86
stable-3.9
21
stable-3.8
22
stable-3.7
4
stable-3.6
0
stable-3.5
4
stable-3.4
1
Total
368
Total of Gerrit verifications:
Type of verification
number of verifications
Build/Tests
277
Code Style
320
PolyGerrit UI Tests
124
RBE BB Build/Tests
271
Total
992
Evolution of Build Tools
The journey of Gerrit’s build tools reflects its growth and the increasing complexity of its CI/CD requirements:
Apache Maven: Up until version 2.7, Gerrit used Apache Maven as its build tool. Maven, known for its comprehensive project management capabilities, was sufficient during Gerrit’s early stages.
Buck: From version 2.8 to 2.13, Gerrit transitioned to Buck, a build tool designed for faster builds. Buck’s incremental build capabilities helped manage the growing codebase more efficiently than Maven.
Bazel: Since version 2.14, Bazel has been the default build tool for Gerrit. Bazel’s advanced features, including its support for remote caching and execution, provided significant improvements in build performance and scalability.
Transition to Bazel with Remote Execution and Caching
In December 2020, Gerrit Code Review made a significant shift by adopting Bazel with remote execution and caching to address the challenges of long build times. This strategic move aimed to leverage Bazel’s advanced capabilities to enhance the efficiency of the CI processes.
Reasons for the Shift
The primary driver for this transition was the increasing build times due to the growing complexity and size of the Gerrit codebase. The conventional local build processes were becoming a bottleneck, slowing down the development and integration cycles.
Implementation with GCP Remote Build Execution (RBE)
Gerrit integrated Google Cloud Platform’s Remote Build Execution (GCP RBE) as the remote server to support this transition. The integration provided several key benefits:
Reduced Build Times: By offloading build and test tasks to powerful remote servers, build times were significantly reduced.
Efficient Resource Utilization: Local machines were freed from heavy build tasks, allowing developers to continue working without interruptions.
Scalability and Parallelisation: Remote execution and the parallelisation of Gerrit’s Bazel tasks allowed to leverage the scalable cloud resources.
This implementation marked a crucial enhancement in Gerrit’s CI/CD pipeline, setting the stage for further optimisations and improvements in the build process.
Motivation to find RBE alternatives
The RBE implementation on Google Cloud has served the Gerrit Code Review project successfully for many years; however, the needs of the project grew over time and the CI/CD infrastructure had to satisfy additional requirements.
Stability: Google Cloud is SaaS solution which could be flaky at times, whilst the project needed a stable deployment with full control on its stability not influenced by external factors.
Latency between the controller and the executors: the latency between the main CI/CD controller (Jenkins) and the RBE executors paid a significant price for shorter builds like the Code-Style checks, whilst a localised data processing resulted in faster build times and quicker feedback cycles.
Predictability: Consistent and reliable performance is crucial for efficient CI/CD workflows.
Moving to BuildBuddy RBE
BuildBuddy is an open-core Bazel build event viewer, result store, remote cache, and remote build execution platform that provided many new benefits to the Gerrit Code Review builds:
Integration and Customisation: the integration with the existing CI/CD pipelines was straightforward.
Open Source Community: BuildBuddy, being open-core, benefits from community-driven innovation and collaborative support.
Enterprise Features: BuildBuddy Enterprise offers advanced features for companies that need robust capabilities:
OpenID Connect Auth Support: Integrates with Google OAuth.
Configurable Bazel Caches TTL: Allows setting TTL for build results and cache with support for persistent build artifact storage.
High Availability: Configurations for high availability also on-premises
Control and Stability: On-premise deployment offers full control and enhanced stability by minimizing reliance on external factors.
Very Low Latency: Localized data processing results in faster build times and quicker feedback cycles: we could locate the executors and the Jenkins controller in the same data-centre with micro-seconds network latency.
Predictable Performance: Consistent and reliable performance is crucial for efficient CI/CD workflows, thanks to the dedicated always-on executors.
BuildBuddy RBE allowed more development efficiency and reliability for the Gerrit Code Review project, making it a compelling choice for optimizing CI/CD processes while leveraging the benefits of open-source software and robust enterprise features.
What was the migration plan ?
To clarify a few points for a better understanding of the this section:
Scope of Bazel RBE Execution: Bazel RBE is executed only in the Gerrit project and its core plugins (git submodules). It is not executed in non-core plugins, such as pull-replication, high-availability, multi-site, etc.
Branch Support: From a CI/CD perspective, only the master branch and the last three stable branches are supported for Gerrit project, core and non-core plugins. At the time of the migration, these branches were master, stable-3.7, stable-3.8, and stable-3.9.
The initial phase of the migration aimed to assess the reliability and stability of BuildBuddy RBE. A priority in this phase was to maintain the current CI/CD process while simultaneously evaluating BuildBuddy RBE without any disruptions.
To achieve this phase, several updates and new services were implemented:
Provisioning BuildBuddy Executors: A cloud host was provisioned with the following specifications: 128 CPUs, Intel(R) Xeon(R) Gold 6438Y+, 128GB RAM, and SSD. This host runs 3 BuildBuddy executors (as docker containers).
Setting up a new Gerrit CI Server: A new Jenkins server was set up to run build jobs against BuildBuddy RBE on the Gerrit master branch. This server is not accessible from outside.
Registering a new Gerrit verification: A new verification named RBE BB Build/Tests was added to gerrit-review.googlesource.com to trigger builds on the new Gerrit CI server whenever a new revision was created on the Gerrit master branch.
Figure 1: Architecture Migration diagram with default CI flow and new BuildBuddy CI flow:
How is the new CI/CD flow?
In the default CI flow, when a user creates a new revision (patch set) in Gerrit master, or stable-3.7 or stable-3.8 or stable-3.9 branches, a set of verification jobs trigger Jenkins jobs. These verification jobs include:
RBE GCP Build/Tests: Builds the codebase and executes all the unit/integration tests on GCP RBE.
Code Style: Checks Java and Bazel formatting, and JavaScript lint.
Build/Tests: Builds the codebase and executes one single no-op test.
PolyGerrit UI Tests: Executes unit/integration tests for PolyGerrit UI.
If any of the verification jobs fail, the verification status of the revision is marked with a -1.
As mentioned earlier, the intention when testing the reliability and stability of BuildBuddy RBE was to avoid interfering with the default CI/CD flow. To achieve this, a new verification job called RBE BB Build/Tests was added. This verification triggers a Jenkins job on the new Gerrit CI, which builds the codebase and executes unit/integration tests on BuildBuddy RBE. This setup allowed the default flow and the BuildBuddy RBE flow to coexist without affecting each other.
It is important to note two things:
Only revisions in the master branch of Gerrit project triggered this new verification job. The data collected from the master branch is sufficient to draw conclusions.
The status of this new verification job does not affect the overall verification status of the revision.
Figure 2: Verification jobs, default ones and the BuildBuddy RBE, triggered in a Gerrit master branch revision:
Once the first phase concluded, it was important to analyze the data to determine if BuildBuddy RBE was reliable and stable enough to proceed to the next phase. In the second phase, the plan was to evaluate the performance of BuildBuddy RBE against GCP RBE. Architecturally, the CI/CD process remained the same as in the first phase, with one key difference: the verification job RBE BB Build/Tests would be triggered when revisions were created for the Gerrit repo on the master, stable-3.7, stable-3.8, and stable-3.9 branches. This was necessary to ensure that BuildBuddy RBE handled the same number of jobs as GCP RBE, allowing for a fair performance comparison.
Data Collection
Before analysing the data, it’s imperative to elucidate our data collection methodology. To procure the build data (build number, execution time in GCP RBE and BB RBE and status), we developed a script in python that employed two APIs:
Build number is a unique number represented by the tuple: (change number, revision number).
All the graphs show builds in chronological order.
The build numbers are not shown in the graphs for readable purposes.
Builds labelled as “RUNNING” or those lacking specification according to the API have been excluded from the calculations.
Key Performance Indicators
Average Build Time: Calculate the average build time for each platform (GCP RBE and BuildBuddy RBE) to understand the typical time it takes to complete a build on each platform.
Percentage of Builds Faster: Determine the percentage of builds that are completed faster on BuildBuddy RBE compared to GCP RBE. This helps assess which platform is more efficient in terms of build time.
Overall Success Rate / Failure Rate: Calculate the overall success and failing rate of builds on BuildBuddy RBE. This considers both successful and failed builds to provide a comprehensive view of platform reliability.
Outliers (>60 minutes): Identify the percentage of builds that exceed a certain threshold, such as 60 minutes in BuildBuddy RBE. This helps pinpoint builds that take exceptionally long and may require investigation or optimization.
Average Build Time Reduction: Determine the average reduction in build time when using BuildBuddy RBE compared to GCP RBE. This quantifies the efficiency improvement gained by using the BuildBuddy platform.
PHASES
As we mentioned above, the migration has been segmented into two distinct phases:
Phase 1: Spanning from December 28th, 2023, to February 9th, 2024, during which RBE BuildBuddy operated against the Gerrit master branch. Phase 2: Commencing from February 10th, 2024, to February 26th, during which RBE BuildBuddy operated against the Gerrit master, stable-3.7, stable-3.8, and stable-3.9 branches.
Phase 1: Evaluate if BuildBuddy RBE offers stability and low latency
To make the data more readable and understandable, I have split the data into 2 graphs:
Figure 3: RBE Successful Build time for Gerrit master between 28th December 2023 to 18th January 2024:
Figure 4: RBE Successful Build time for Gerrit master between 19th January 2024 to 9th February 2024:
Total number of builds:
master
GCP Builds
489
BB Builds
489
Build status:
BB Successful
BB failed
GCP Successful
390
17
GCP Failed
0
82
Initially, 3.47% of BuildBuddy RBE builds failed due to CPU exhaustion caused by running 100 BuildBuddy executors simultaneously. This problem was addressed by reducing the number of executors to 3. BuildBuddy engineers advise running only one executor container per host/node, with each executor capable of handling multiple RBE Actions concurrently. For each action, an executor initiates an isolated runner to execute it. We plan to reassess our configuration in due course.
Average build time when GCP and BuildBuddy builds were successful:
Minutes
GCP Average
18.69
BB Average
10.2
Where the average build time reduction is 8.49 minutes and 96.4% (376 out of 390 builds) of BuildBuddy builds are faster than GCP builds.
We discovered that 1.5% of BuildBuddy successful builds were outliers. This was due to the need for a restart of the new Gerrit CI server, which caused temporary disruptions.
change_number
REVISION_NUMBER
GCP RBE MINUTES
BB RBE MINUTES
400398
1
6.7
868.68
399657
11
13.7
1293.55
399657
14
21.45
137.47
400958
2
14.52
154.3
247812
7
26.62
67.17
406597
1
14.18
79.55
Average time when GCP and BB Failed:
Minutes
GCP Average
17.68
BB Average
23.29
Conclusions:
Assessing performance and stability, the results were promising, with the BuildBuddy platform showcasing superior performance, as highlighted in the table “Average build time when GCP and BB Successful”. Additionally, issues with BuildBuddy failing builds during successful GCP builds were addressed, primarily stemming from resolved configuration problems. Although outliers represented a mere 1.5%, their significance was negligible. However, despite these favourable outcomes, caution was warranted due to the higher volume of builds in GCP compared to BuildBuddy, attributed to GCP’s operation across stable branches.
Phase 2: Compare BuildBuddy RBE with GCP RBE based on performance
To make the data more readable and understandable, The data has been splitted into 4 graphs:
Figure 5: RBE Successful Build time for Gerrit master:
Figure 6: RBE Successful Build time for Gerrit stable-3.9:
Figure 7: RBE Successful Build time for Gerrit stable-3.8:
Figure 8: RBE Successful Build time for Gerrit stable-3.7:
Successful BB Build status / Successful GCP Build status:
master
stable-3.9
stable-3.8
stable-3.7
Total
Builds
119
26
6
11
162
Average time when GCP and BB Successful:
Minutes
GCP Average
13.91
BB Average
8.45
Where the average build time reduction is 5.46 minutes and 90.74% (147 out of 162 builds) of BuildBuddy builds are faster than GCP builds.
Failed BB Build states / Failed GCP Build status:
master
stable-3.9
stable-3.8
stable-3.7
Total
Builds
30
12
1
1
44
Failed BB Build status / Successful GCP Build status:
master
stable-3.9
stable-3.8
stable-3.7
Total
Builds
1
2
0
0
3
It is worth noting that 1.14% of BuildBuddy builds failed.
Average time when GCP and BB builds failed
Minutes
GCP Average
10.96
BB Average
9.43
Conclusions:
The findings indicated that the BuildBuddy scenario demonstrated a more consistent performance, due to the on-premises allocated resources, as emphasised in the table “Average build time when GCP and BB Successful,” with comparable volumes of builds. Moreover, the stability remained highly consistent, evident from the table “Failed BB Build status / Successful GCP Build status,” alongside the absence of outliers.
Gerrit code review community decision
On February 27, 2024, the collected data was shared with the Gerrit code review open-source community. After careful consideration and thorough analysis, BuildBuddy was found to demonstrate remarkable stability. While it cannot be definitively stated that BuildBuddy surpasses GCP in all aspects, it notably outperforms GCP in terms of latency. Given its superior latency performance and strong stability, the decision was made to adopt BuildBuddy to replace GCP in the CI/CD pipeline.
Configured Gerrit CI to support both core and non-core plugin jobs, ensuring external visibility.
Unregistered the Gerrit verification RBE GCP Build/Tests on gerrit-review.googlesource.com.
Figure 9: Default Architecture diagram with BuildBuddy CI/CD flow as default CI/CD flow:
Final Conclusions
Following the completion of the migration, data on BuildBuddy RBE was collected from May 1, 2024, to June 24, 2024, to validate all assumptions. Subsequent statistical analysis yielded the following results:
Figure 10: Successful Builds:
Builds
465
Mean
13.62 min
Median
10.47 min
Standard dev
10.79 min
A higher standard deviation indicates that the build times are spread out over a wide range, meaning there is a lot of variability in the times
Q3
15.23 min
75% of builds are completed in less than 15.23 minutes.
Figure 11: Failed Builds:
Builds
105
Mean
7.72 min
Median
6.22 min
Standard dev
7.56 min
Q3
7.7 min
75% of builds are completed in less than 7.7 minutes.
While we are satisfied with our current results, we recognize the need for improvements in our successful builds. Our next step will be to analyze all the build data provided by the BuildBuddy dashboard, including target-level metrics, timing, artifacts, cache, and executions. This analysis will help us enhance the Bazel configuration and improve build performance.
It has been seven years since we first introduced the native packages for Gerrit Code Review. At that time, Docker was just two years old and was starting to pick up momentum: the native packages found their first incarnation in the Gerrit Code Review base on images published on DockerHub.
Since then, Gerrit has always been released as both a “plain vanilla” war file and the equivalent “native packaging” flavors, including the base Docker images.
In the beginning, the release managers mainly used the Gerrit Docker images to simulate pre-configured test environments for testing purposes. However, the adoption spiked up when Kubernetes and AWS Container Services (aka ECS) started to become mainstream.
Nowadays, the Gerrit base images on Dockerhub are pulled millions of times and used as the baseline for creating Enterprise-grade setups, like in the aws-gerrit recipes.
x86 Native Packaging
Even though it wasn’t initially thought off, the native packages ended up mainly in x86-based containers, even though Gerrit is a 100% pure-Java application. How was that possible?
Dependencies: gerrit.sh requires some basic OS services to work properly, including the native git command line.
Build & testing: the build of gerrit.war and associated testing was always performed on x86, also due to the restrictions of the platform supported by Bazel at that time.
ARM-64 takes off
The ARM processor comes from the historical legacy of Acorn Computers Ltd, a British-born company of the 80s, well known for the BBC Micro project. Back in the 90s, a new joint venture was created with Apple Computer and VLSI Technology to design a brand-new Advanced Risc Machine (aka ARM).
Over time, ARM has created first a 32-bit architecture and subsequently a 64-bit architecture processor, well known and appreciated for its low-power consumption and performance efficiency.
Whilst Intel, with its x86 architecture, dominated the desktop and the server market, the ARM architecture found its natural market space in the low-power devices and, more recently, the mobile phones market.
Apple goes ARM-64, everywhere
Apple initially adopted the ARM architecture on its mobile phones and portable devices, licensing the instruction set to build its microchips in 2010. Ten years later, Apple announced it was also transitioning all the other desktop devices to its ARM-based silicon.
Nowadays, nearly all Apple laptops are on ARM and the other devices are migrating to that too. The applications are rapidly adapting to the new instruction set and getting rebuilt quickly, gaining in both performance and increased battery life.
Cloud services are moving to ARM-64 too.
The move from x86 to ARM-64 brings noticeable advantages in terms of costs and energy efficiency has been recently amplified by the increase in the costs of electricity triggered by the spiked wholesale prices of oil, gas, and other fossil fuel.
GCloud (see T2A offering ) and AWS (see EC2 Graviton) offer now ARM-64 based VMs that promise a healthy 60% reduction of cloud hosting costs and higher throughput and performance per $.
Gerrit has always put high performance and low operating costs at the top of its agenda, allowing companies to keep their development teams highly productive with minimum dedicated staff looking after the system.
Now it is also time to reduce the Gerrit Code Review Cloud hosting costs and increase efficiency while preserving all the benefits that Gerrit brings.
Introducing ARM-64 native packages for Gerrit Code Review
Gerrit Code Review native packages are now available for ARM-64 on all its recent releases, from v3.4.8 onwards. If you are currently running on x86, you can easily switch to ARM-64 transparently by just rebuilding from the base image. All the DockerHub images have been repackaged and republished:
On Debian, just refresh the repository cache with ‘apt-get update‘ and the new packages will automatically show-up and be available for setup.
Because this is a repackaging of the existing Gerrit release, the 4th number of the package name has been updated, e.g., gerrit-3.4.8-2 is the package name associated with the ARM-64 compatible package.
Ready to switch to ARM-64?
The Gerrit maintainers have already switched to ARM-64 with the recent wave of MacBook upgrades: all the non-EOL Gerrit releases are typically developed on Apple M1 or M2 which are based on ARM-64 rather than x86.
The need to reduce costs and the overall carbon footprint of the Gerrit project would most likely drive the CI agents’ switch to ARM-64 very soon.
Are you ready to switch to ARM-64 to reduce your operating costs and help the planet by reducing your Gerrit consumption?
Q&A
Q1. Are Gerrit on x86 and ARM-64 compatible in terms of data?
Yes, because the underlying data structure is platform-independent and is all based on Git, which is already interoperable cross-platform.
Q2. Can I mix&match x86 and ARM-64 Gerrit nodes?
Yes, by adopting the Gerrit multi-site setup, you can configure and host different sites on different architectures.
Q3. Will Gerrit on x86 continue to be supported?
Yes, because we want to allow the Gerrit administrator to choose the most suitable platform for his users and compatible with his Company’s requirements.
An important part of the summit are the lightning talks, ten-minute talks that intend to present research or demos and work in progress within the Gerrit Code Review.
Join Ian Gauthier, Flywheel.io who will present research performed to evaluate the extent to which historical data is an appropriate benchmark for reviewer recommendation systems. In another session Paul Jolly, CUE demonstrates how the CUE project uses GerritHub in combination with GitHub Actions for Continuous Integration and regression testing. And don’t miss out the live demo and presentation of the AWS-Gerrit project by Antonio Barone, GerritForge with the integration with AWS X-RAY, as part of the efforts to bring Gerrit to the cloud.
It has been a challenging year, a strange year, for everyone. Most of us confined in our homes and working remotely, finding new ways of dealing with old problems.
Still, we believe the Gerrit Community as a whole has demonstrated an outstanding level of resilience in the face of exceptional difficulties. As far as we are concerned, we have seen no lesser activity, interest, new projects, compared to the previous years. For this, we are thankful to the community we are so strongly proud of being a part of.
In sharing our most sincere vows for happy festivities and a fruitful new year, we wanted to take the opportunity to share with you some of the achievements that made this 2020 worth getting through.
Top-Ten achievements in 2020
1. GerritForge has confirmed to be the world’s largest non-Google contributor to the Gerrit Code Review project.
GerritForge contributed almost a thousand changes merged, over 47 different components in the past 12 months. That is an outstanding achievement confirming the commitment and dedication of the company to the Gerrit Code Review platform and community.
2. Improved Gerrit DevOps Analytics with the ability to process Changes hashtags
The Gerrit DevOps Analytics platform continued to expand its possibilities, with the full support of the parsing of the NoteDb changes and the extractions of precious meta-data, such as the changes hashtags.
3. Driven two major releases of Gerrit Code Review
GerritForge helped driving the release of two major Gerrit Code Review version: Gerrit v3.2 – 1st June and with Ericsson making the Gerrit v3.3 – 1st December. GerritForge is also providing the CI/CD pipeline for the build and validation of the releases and helped the migration to Java 11.
4. Released major security fixes for the whole Gerrit Community, of all Gerrit versions dating back to v2.14
5. Brand-new Gerrit module cache-chroniclemap, a new high-performance persistent cache in Gerrit v3.3
GerritForge continued its efforts in improving Gerrit’s scalability and performance with the development of a brand-new persistent cache backend powered by ChronicleMap, showing unprecedented low latency and performance on Gerrit v3.3.
6. Introduced the world-first official Open-Source AWS-based Gerrit Code Review Deployment
In a year of remote working and flexible environments, GerritForge provided its contribution to the whole community to help adopting Gerrit in the cloud. The aws-gerrit project is a brand-new production-ready AWS deployment now available for everyone and fully Open-Source. The new project is based on the GitOps best-practices and has been successfully adopted for the testing and validation of Gerrit v3.3.
7. New read-write scalability for Gerrit in High-Availability
GerritForge’s mission to scalability and high-availability (HA) plugin continued with the ability to scale horizontally with multiple R/W Gerrit Servers behind the same load balancer.
8. Improved reliability and flexibility of Gerrit Multi-Site
The Gerrit Multi-Site (MS) plugin has received exciting improvements with the support for geographically distributed R/W Gerrit servers across the globe.
9. Brand-new pull-replication plugin for improving latency and performance of large mono-repos replication.
The need to have Gerrit multi-site brought the request to have faster replication, especially for large mono-repos. GerritForge introduced a new pull-replication plugin project that, used in conjunction with Git Protocol v2, assure top-notch performance in replicating repositories with large number of refs.
10. Helped large-scale OpenSource Community migrating to Gerrit v3
The Eclipse Foundation and the OpenDev platform (by OpenStack), upgraded to the latest version of Gerrit Code Review, thanks to the continuous help and support from GerritForge and the rest of the Gerrit Code Review community.
All the best, Stay Safe, and we will shake hands again soon!
Gerrit Code Review has begun the Ver. 2.11 release cycle and the first release candidate been released this morning on Gerrithub.io.
Entering into the battlefield
Gerrit is entering for the first time into the field of Cloud based IDE integrating a Browser-based editing functionality into the code review lifecycle. For the very first time you are just a couple of clicks away from a review-edit-submit turnaround: see below the additional icon to access the functionality from the Gerrit change screen.
What is in-line edit and how can I use it?
As this is a brand-new functionality with a complete new UX, a new dedicated page has been published to guide through the new functionality.
You can experiment today the in-line edit by creating a new project on GitHub and sign-in to GerritHub.io. The new turnaround is quick and the flow is splendid ! This has been a masterpiece in collective code ownership and review of the Gerrit Team; this feature has been lead by David Ostrovsky after a series of early betas shared and discussed collectively.
What else is included in Gerrit 2.11?
A lot of new enhancements are coming, mainly related to the improvements of Gerrit REST-API to support this new feature.
We foresee a near future where Gerrit becomes the central hub of the code-review and integration workflow, together with a CI engine such as Jenkins. It has recently proposed a new build of Gerrit without a GUI and exposing its review capabilities in headless mode: the presentation logic will then be implemented by the various UX plugins integrated with other IDEs.
Should this scenario materialise as future of Gerrit, we will soon see other UX that will expose the power, flexibility and scalability of Code Review system in a brand-new HTML5 or native experience.
The IntelliJ and Eclipse plugins are already a reality of this, but more will come and I bet they will be more focused on the Cloud IDE use-case.
GerritForge Blog 