My First Ruby Contribution to GitLab: From Golang to the Monolith

Introduction

In this article, I’ll tell you the story of how, unexpectedly, my contributions to GitLab led me to my first ever contribution in Ruby. Now, I am well aware that Ruby is the primary programming language at GitLab, but my focus was—and will remain—on providing real value to the platform using Golang, which is the language I master and the main reason I decided to start contributing in the first place.

The Context

As you might know if you follow my posts, I am a GitLab Notable Contributor. I earned this recognition mainly through my contributions to the client-go and terraform-provider repositories, both developed in Golang.

While GitLab’s main language is Ruby, many high-performance services, such as the GitLab Runner, are developed in Golang due to the clear advantages of the language regarding performance and concurrency.

Basically, the issue arose while I was working on this issue for the Terraform provider. Along with the maintainers, we realized that we needed to make a change in the GitLab Monolith to complete the solution. This represented a challenge for me for two main reasons:

• I had never developed anything in Ruby before.
• The GitLab monolith is a massive and complex project, full of specific nuances I wasn’t familiar with.

The Solution

I spent a significant amount of time on this merge request. First, I had to understand the Ruby code structure, then implement and test the necessary changes, and finally, handle the unit tests (which, by the way, were quite numerous). Throughout this process, there was a lot of back-and-forth with the project maintainers. Once they realized this would be a significant change, they requested that I implement a feature flag for this new functionality.

Without getting too deep into the technical weeds, the change consisted of allowing the creation of tokens (both personal and resource tokens, whether project or group) without specifying an expiration time—provided that the require_personal_access_token_expiry setting was disabled.

The problem was that the monolith validated that the expires_at field was always present in the request; if it wasn’t, it returned a Bad Request. To fix this, I modified the validation so that if the mandatory expiration setting is disabled, the expires_at field can be absent from the request.

I should mention that despite being my first Ruby contribution, it was a very comprehensive MR involving a large number of changes—mostly due to the extensive modifications required in the tests to account for both states of the feature flag.

Ruby, a “Magical” Language

Before giving my opinion on Ruby, I want to clarify that I have extensive experience with high-level languages like Node.js. I understand perfectly that these languages often allow developers to abstract away many details that in languages like Golang, you must handle explicitly.

Perhaps the best example isn’t Golang, but rather languages like C or C++, where in addition to pointers, you must manually manage memory allocation and deallocation.

With that in mind—and considering I didn’t focus on mastering every aspect of Ruby but rather on solving the specific problem at hand—it seems to me that Ruby on Rails is a quite “magical” framework. It feels as though many things happen behind the scenes by magic. Again, this is just my first impression following this contribution, and I am certainly not an expert in Ruby or Rails.

Until Next Time

I hope you found this experience helpful. If you enjoy these kinds of articles and want to learn more about my journey as a software engineer and GitLab contributor, I invite you to subscribe to my newsletter using the form at the bottom of the page. See you in the next post!!!