Skip to content

Add Zack Cuddy as Frontend Maintainer of GitLab

Zack Cuddy requested to merge zcuddy-frontend-maintainer into master

Self-assessment

It's hard to specify hard requirements for becoming a maintainer, which is why the documentation consists of flexible guidelines. Nevertheless, it's still important to have a more formal list to help both a candidate and their manager to assess the "readiness" of the candidate.

  • Advanced understanding of the GitLab project as per the documentation:

    good feel for the project codebase, expertise in one or more domains, and deep understanding of our coding standards

  • The MRs reviewed by the candidate consistently make it through maintainer review without significant additionally required changes.
  • The MRs authored by the candidate consistently make it through reviewer and maintainer review without significant required changes.

Links to Non-Trival MRs I've Reviewed

To save from bloating up this MR I simply linked each item back to the summary on my trainee FE maintainer issue. There you will find a bunch more context around the review on each change. Naturally there are more examples than listed here on said issue: #7376 (closed) 🚀

Links to Non-Trivial MRs I've Written

Going to work in most recent -> least recent here. All my contributions at GitLab can be found here: https://gitlab.com/dashboard/merge_requests?scope=all&state=all&author_username=zcuddy

Global Search - Replace deprecatedJqueryDropdown with GlDropdown

  • This change ended up splitting up between 19 MRs over 8 months 😅
  • This was a massive endeavor to refactor the Global Navigation Search (the one at at the top of your screen in the nav bar) from the deprecatedJqueryDropdown to GlDropdown.
    • This was done to better setup this component for more feature expansions
  • This change additionally completely overhauled the A11y of this component. The deprecated component did not properly support keyboard navigation and had no screen reader support
    • One of the most fantastic and intense MR review sessions of my career occurred throughout this a11y effort and can be checked out here: gitlab-org/gitlab!70222 (merged)
  • This change didn't come without its own challenges. Most significant was my blunder that ended up exposing sirt_2010. More on that below 😬

Geo: Implement the new design of the Geo node page

  • This change ended up splitting up between 12 MRs over 2 months. Adding over 4,000 lines of code 😲
  • This was an exciting endeavor of consolidating all our user research from customers into rebuilding the Geo UI into a functional view with many improvements.
    • Being the only FE team ember in ~"Enablement Sub-department" at the time I was charged with organizing this from start to finish from the technical aspects. I was able to provide this plan here: gitlab-org&4712 (comment 449512391)
  • This was an awesome experience as we got to start from ground zero rebuilding the entire UX for our stakeholders!
  • By all accounts our customers loved this change and unlike the search change above there wasn't really anything negative that came out of this change 🎸

Global Search - Convert UI from HAML -> Vue

  • As mentioned above prior to February 2022 I was the only FE team member in ~"Enablement Sub-department". After some of my successes with Geo (found below this section), Global Search requested I switch focus to their product.
  • Converting the UI from HAML -> Vue was a huge learning experience for me.
    • Prior to helping here I had the mindset of "EVERYTHING TO JAVASCRIPT!!"
    • Throughout working and suggesting this effort I found there are middle grounds and solid use cases to keeping some of the FE in HAML/Rails. I reflected on this growth in a write up here: gitlab-org&4532 (comment 752300877) 🤔
  • Aside from the later change in mindset, I used this Epic as an implementation plan and wrote up a large proposal explaining my through process and the possible wins. (Lots of threads and conversations on this Epic dug into this
  • Eventually we built a flexible UI that included some large Vue frontend elements surrounding the HAML/Rails served search results.
    • Here I built a shared Vuex store that 3 different Vue instances communicate with and amongst each other.
    • This was my first experience building this sort of Hybrid layout and it was incredibly exciting 💥

Geo: Implement frontend for Self-Service Framework replicables

  • This was my first "major" feature a few months after joining GitLab!
  • This was what we ended up referring as the "Generalization of Geo".
  • The main goal here was to build the Geo UI to represent similar data in a uniform way. This data is called a "Replicable"
  • The catch is that "Replicables" are served 3 different ways 😧
    • Type A (No API)) - Served via Rails Controller and rendered via hard-coded HAML view
    • Type B (RESTful API) - Served via a RESTful API and rendered via flexible Vue components
    • Type C (GraphQL API) - Served via a GraphQL API (possibly user created via SSF framework) and rendered via flexible Vue components
  • Before this change we only rendered Type A and B.
  • This effort was to build a flexible Vue application that could handle the RESTful and GraphQL data and format the data into a consumable format for the UI regardless of its source. The HAML views were then just modified to match the Vue component and deprecated.
  • The end result of this change allowed Geo to fully adopt the SSF framework the backend engineers had been working to build and any "replicable" added via the SSF framework would "magically" just appear in the UI without any additional code from any engineer.

Rewrite Geo Node Form in Vue and Rewrite Geo Settings Form in Vue

  • Both of these changes were my first significant changes at GitLab 🎉
  • These changes were brought up by the goal of adding async form validations before a user submits the forms
  • This felt best approached by converting the forms to GlForm and adding validation logic using the input/blue events.
  • This also in result moved everything of the Geo UI in to Vue for consistencies sake.

Examples of challenging situations

Prelude

When thinking of mistakes there is one glaring one that comes to mind. This occurred as part of the effort to Replace the deprecatedJqueryDropdown with GlDropdown.

On 2022-02-21, reports of a leaked Runner Token was reported via HackerOne. This ended up being referred to as sirt_2010. Runner Tokens of Projects were being leaked via the HTML data- attributes. This was happening via a class @search_context being to_json to send search data to the Frontend as part of the new header search component.

This was unintentionally fixed via an MR I wrote after introducing the bug but before it was caught to "slim down" the amount of data we were sending to the UI. This removed the Runner Tokens from the UI but still left any token served between December and February to have been previously exposed.

Later it was found that there were older similar examples of runner tokens being leaked up towards 2 years ago and was referred to sirt_2020. This in a way drew attention away from the bug I introduced. However the fact the remained that I committed the biggest mistake of my career.

**How it happened?**

At the root of it all, how this happened was by my negligence in understanding everything I was providing to the Frontend. As part of the discovery I simply JSONed the entire @search_context object (which was used in the legacy HAML views for the search). I then iteratively reverse engineered the @search_context to understand all the features and "search information" I needed to preserve in the new header search field.

However, after I replicated the functionality in the refactor I never looked back at "everything else" in the @search_context. Instead I pushed on to releasing the feature on GitLab.com. Eventually I went back and addressed the extra data but it was far too late as tokens had been exposed for 2 months at this point. This was just days before the vulnerability was found.

In retrospect the reason this happened was:

  • A bold assumption that @search_context is safe data right?
  • A arrogant assumption that over sending data to the frontend isn't that big of a deal?

These assumptions ended up burning big time down the road.

**What did I do?**

To make matters worse, this bug was exposed the same day I was in the hospital experiencing the birth of my first son Theodore 👶. I was hopping on to Slack to check in on my team members in Ukraine (in leu of the current events) when I saw snippets of text about sirt_2010.

I started scrolling and that is when panic followed by dread settled in 😨 I caused a massive bug that made GitLab vulnerable and there was nothing I could do about it.

I spent a good chunk of my parental leave with anxiety of the exposure. During my free time I stayed in the loop, reached out to team members, and tried to support how I could from afar. I really realized during this how awesome of a team we have here at GitLab at how quickly things were addressed. Thankfully there was no real reported damage from this mistake but it really could have gone so much worse.

**How did I grow?**

Moving forward I have a strong ruleset to treat anything I send to the frontend with rigor and confidence. I never will take for granted putting something in the DOM without first verifying what it is and why I need it.

This whole experience has really exposed to me how important security is for a Frontend Engineer and has opened a whole new avenue of security awareness as I continue to contribute.

Additional contributions

@gitlab-org/maintainers/frontend please chime in below with your thoughts, and approve this MR if you agree.

cc/ @nhxnguyen @cdu1

Once This MR is Merged

  1. Create an access request for maintainer access to gitlab-org/<project>.
  2. Join the [at]frontend-maintainers slack group
  3. Let a maintainer add you to gitlab-org/maintainers/frontend
  4. Announce it everywhere
  5. Keep reviewing, start merging 🤘 😎 🤘
Edited by Zack Cuddy

Merge request reports