Mastering GitLab REST APIs: A Senior Engineer's Real-World Solution

When it comes to senior engineers, most non-tech or some techie people start assuming, that senior engineers mean they know "how to code" better than the other non-senior ones. This statement can be considered true, but it does not do justice to the real ones.

My personal belief is, that senior engineers have qualities, that are not limited to just "better code", in fact, in a very controversial way, I can proudly say, that, there are some senior engineers who code similarly to non-senior engineers, but still they are better at their jobs than the non-senior ones. Yes, code is not the only parameter to measure seniority. It is mostly about your thinking process, approach to solving the problem, and whatnot!

Thank god we are not here to understand the role of senior engineers just by throwing out some techno-philosophical words. I am going to detail a real-world problem that I solved at my work, which will help you understand the title of this post.

The Problem

The GitLab allows 5 users to use the free tier of their app. We have our previous website's (solutelabs.com) codebase & CI hosted on GitLab. We have our blogs hosted on headless CMS sanity. When there is a content change, we need to run a CI pipeline in gitlab app to get all the latest content from our headless CMS. Now, the changes in the sanity headless CMS are handled by our marketing and branding team and we should not/cannot give access to GitLab to them as they are non-technical users. We could have put a webhook in sanity itself, but there are some problems if we do that, which we will not discuss in this post, but, we will just assume, that it cannot be done.

So, the bottom line, is, the marketing and branding team needs to trigger a pipeline on gitlab themselves and we are not going to give them access to a GitLab account.

The Rumination (lasted for 5 minutes 😇)

Rumination means thinking about a solution to a problem for longer.

The rumination and the period it lasts can explain the seniority of an engineer. When I was introduced to this problem, I simply thought, there must be some way to trigger the build from outside of the GitLab app ecosystem.

When continuous integration (CI) is implemented, it typically involves triggering multiple webhooks for various purposes. And, it is GitLab's app (or backend) that is triggering those webhooks. Now, here it is, when my inner senior engineer wild guessed that, there must be GitLab REST APIs (might be free to use, might not be) that can be available for us to do so.

I named it a wild guess, but, to be honest this was not a wild guess. The reason is, that I am a big fan of automation and always have brainstormed on architecture on how CI platforms work. While utilizing GitHub Actions on a late Friday night, I delved into the codebase of an individual GitHub action to grasp its inner workings. Upon investigation, I found it comprised only REST APIs from GitHub and nothing fancy, not even a software SDK.

This gave me an idea about different CI platforms' architecture and not just GitHub Actions. That late Friday night, when I explored GitHub Action's code base, was fruitful after all these years.

This exploration was not out of the blue, I hate blackboxes in general. I hate when something is magic to me, I always have the urge to open things up whenever possible. I always look into my node_modules, open source library's codebases, and whatnot.

Here, I quickly grabbed the documentation of GitLab REST APIs and figured out a few useful APIs as per our use cases.

1. Trigger pipeline API -> from which they trigger the pipeline

    /api/v4/projects/{project_id}/trigger/pipeline?token={api_token}
   

2. Fetching the latest pipeline status -> They can see the latest pipeline status and how much time has passed running it.

    /api/v4/projects/{project_id}/pipelines/latest
   

I figured there was a way, but, the challenge was, that the api_token required to trigger the pipeline might get exposed to the client-side env variable, making anyone trigger the pipeline, once they just got access to the app.

I leveraged the use of /api folder in the NextJS app, and exposed an API, which worked only on giving some passwords pre-stored in the NextJS backend, hence, no need to know a fancy API key, only an easy password entering the frontend, which solves the problem for the marketing team to trigger the pipeline.

I did not just give them the flexibility to trigger the pipeline, but also, gave them UI to show the status of the latest pipeline status as well. You can visit the repo here, it has been recently pushed to GitHub. Visit here -> mohitsinhchavda/gitlab-remote-triggerrer (github.com)

Also, keep in mind, that this was for an old tech stack of our website, and now, we have updated our tech stack to use Incremental Static Generation (ISR) of the NextJS.

So, this was all I wanted to share. If you aim to be a senior engineer, don't just aim to code cleaner by following all the problems. Start thinking about real-world problems around you, and solve them. Sometimes, it doesn't matter how simple the code of my solution given above, what matters is, that I approached the problem by taking it as a challenge and solved it by giving a minimalist solution that required the least amount of code, but it solved a worthy of being called a big problem for us.

The Conclusion

The conclusion here is, that real engineers should always be eager to solve real-world problems and not just be limited to polishing codebases, following best practices, doing quality code, and knowing new technologies. Until and unless you do not try to think and solve these kinds of problems, you should not be called a senior engineer TBH.

I am working on solving another real-world problem, which is quite a bigger app that involves a full-fledged backend server. I am hoping to complete it ASAP.

Want to connect with me? You can reach out via email at mohit.chavda1997@gmail.com or if mail is too boring for you, follow me and DM me on Instagram at instagram.com/mohitsinh.js.