One of the coolest things about working at GitLab is that every line of code I write is source-available, and most of it is open source.

As a result, my public contributions to GitLab serve as an unusually detailed record of my professional work:

• All merge requests authored by me
• All issues opened by me
• All commits authored by me
• My recent GitLab.com activity

Below are some of the highlights of my time at GitLab, complete with links to all the nitty-gritty details.

Merge trains

One of the most interesting features I helped build during my first year at GitLab is merge trains, a conceptually simple feature with a lot of behind-the-scenes complexity. I wrote the majority of the frontend code for this feature; here’s a list of all the merge train-related merge requests I put together:

• !21572: Add example of .gitlab-ci.yml that uses only: [merge_requests] and excludes specific branches
• !21556: Show “merge immediately” dialog when MR’s pipeline has not yet finished
• !21060: Add documentation for new “merge immediately” workflow for merge trains
• !20054: Add warning dialog when users click “Merge immediately” merge train option
• !15535: Resolve “Rename `ATMTWPS` to `MTWPS` in code”
• !14894: Fix the merge button dropdown
• !14097: Add merge train helper text to merge request widget
• !14064: Add merge train position indicator
• !12156: Update the merge request widget’s “Merge” button to support merge trains
• !10803: Add “Allow merge trains” option to project settings page

GitLab Pages + Let’s Encrypt

This feature was particularly fun to develop since I was part of the target audience!

• !26438: Add Let’s Encrypt option in Pages domain new/edit Haml form

Releases page

Since I’m a part of the Release Management group, it should come as no surprise that I spend a lot of time modifying the Releases page.

REST → GraphQL Conversion

When I joined GitLab, we had just started building out our GraphQL endpoint. Now, our goal is to make GraphQL the primary means of interacting programmatically with GitLab.

I took this to heart, dug into in the graphql gem, and built out all of the Release REST APIs in GraphQL:

• !30753: Add basic Release GraphQL endpoint
• !30873: Add additional data to Release GraphQL endpoint
• !33538: Adjust permissions for Release data in GraphQL endpoint
• !33612: Add links to Release data from GraphQL endpoint
• !35066: Add milestone stats to GraphQL endpoint
• !40147: Add total count of project releases to GraphQL endpoint
• !41170: Add release direct_asset_url to GraphQL
• !41183: Add release upcoming_release field to GraphQL
• !45577: Update GraphQL endpoint to support sorting releases
• !46161: Add link paths for release progress view to GraphQL
• !46263: Add GraphQL mutation to create a new release
• !46611: Add GraphQL mutation to update a release
• !48364: Add GraphQL mutation to delete release
• !54605: Add GraphQL mutation to create release asset link
• !56265: Add GraphQL mutation to update release asset link
• !56417: Add GraphQL mutation to delete release asset link

Then, I updated our frontends to use this new GraphQL data:

• !56882: Convert individual release page to VueApollo
• !61828: Convert Releases index page to Apollo Client
• !62234: Add pagination controls to new Releases page
• !62848: Add sort controls to new Releases page

This conversion made it easier to implement some frontend performance improvements:

• !63528: Progressively load releases on the Releases page
• !63914: Update the Releases page to make use of startup queries

The part I’m most proud of? Despite swapping out the entire backend of the Releases page, no one’s seemed to notice 😀

Associating Releases to Milestones

As of GitLab 12.5, Releases can be associated with one or more Milestones. Developing this feature involved lots of small changes throughout the codebase:

• !16558: Add Release Links to Milestone List Page
• !16562: Add milestones to release blocks
• !17091: Update release blocks to support multiple milestones
• !17150: Allow release blocks to be scrolled to using URL anchor tags
• !32360: Add `id` attribute to release blocks
• !17278: Add links to associated release(s) to the milestone detail page sidebar
• !19581: Document Milestone <> Release feature

Allow Releases to be created and edited through the UI

When I joined GitLab, Releases could only be created or modified using the Release API. This (still ongoing!) effort helped make Releases simpler to use:

• !18033: Add “Edit Release” page
• !18411: Add “edit” button to release blocks on Releases page
• !19226: Update release blocks to look for correct property name in API response
• !19321: Update “Tag name” help text on Edit Release page
• !19595: Add documentation for new “edit release” feature/page
• !20075: Update “Edit release” page feature flag to be enabled by default
• !21425: Update the “Edit release” feature’s version from 12.5 to 12.6 in the documentation
• !21767: Remove the :release_search_filter feature flag
• !23810: Remove test that referencesrelease_edit_page feature flag

Add a “dedicated” Release page

Originally, the only way to view GitLab Releases was on the Releases page, which showed all Releases for a given project. This feature added a new page — a Release page — that displayed a Release individually:

• !23792: Create backend route for dedicated Release page
• !23816: Make titles on the Releases page link to dedicated Release page
• !23896: Add “self” link to Release API response

Releases page upgrades

Some modification to make the Releases page more valuable:

• !19451: Move release meta-data into footer on Releases page
• !19448: Add issue stats to release blocks on the Releases page

Release searching

As part of our effort to make Releases more useful, we added the ability to search for issues and merge requests by Release:

• !18761: Add “release” filter to issue search
• !19315: Add “release” filter to merge request search
• !19951: Update documentation for new “Release:” filter
• !20076: Update release search filter feature flag to be enabled by default

DORA 4 metrics

DORA 4 is a set of metrics that gauge the health of a DevOps team. I implemented DORA 4 charts within GitLab, and played a significant role in the design of the API.

• !50885: Add deployment frequency charts to CI/CD Analytics page
• !57872: Add project-level DORA lead time graphs
• !61053: Add group-level deployment frequency charts
• !62941: Add group-level lead time charts
• !64961: Add project-level DORA metrics to GraphQL
• !65279: Add group-level DORA metrics to GraphQL

Quality of life

Every once in a while I step outside the boundaries of the Release Management group and fix something that bugs me:

• !20738: Add `pngquant:compress` and `pngquant:lint` rake tasks
• !16545: Suppress AJAX errors caused by browser navigation
• !27683: Make pipeline failure Slack notifications prettier and more informative
• !25925: Add core-js polyfill for Promise.finally()
• !594: Allow GlTooltip delay to be customized through localStorage

Keyboard shortcuts

This could probably fit into the “quality of life” category above, but it’s consumed enough of my time that it’s worth calling out separately.

I care a lot about keyboard accesibility, and I’ve taken it on myself to make sure GitLab has best-in-class keyboard support.

I recently implemented a few nice-to-have shortcuts:

• !40328: Add Markdown editor keyboard shortcuts

And I’m currently working on a much more ambitious redesign of how we implement shortcuts:

• #251226: Allow keyboard shortcuts to be customized