Entering the third week of my startup adventure has been a deeply rewarding time of solidifying foundations. Things come together to form an official brand, I put together tools to help with financial discipline, and I finished off the week by practicing my own Documentation-as-a-Contract (DaaC) framework.

We Have a Name: Wabe Labs

While I have an idea that I truly believe in and know exactly the components I need to build, I have been feeling excited about this venture before starting. But one question that would keep entering my mind, “What do you tell people your business is called?”

In my first post, I wrote about why I spent my first week writing zero business logic and instead built rig - our lightweight, POSIX-compliant local provisioning tool. It was my way of rejecting “wiki-ops” and applying Infrastructure-as-Code (IaC) discipline to our local environments so that a hardware failure means minutes of downtime, not a week.

But as I transitioned into Week Two, I was hit by a different kind of operational reality check.

Being made redundant from a position where I defined patterns and practices for a high-performance team, I decided to take the leap to create my own startup. As I write now, this has felt like a violent acceleration of the clock. One day you feel the safety of an established enterprise; the next, there I am, standing on a clean slate. When I finally received my new laptop last week, I felt the sudden urge to rush, install the software I needed, and start churning out lines of code.

Through this article, we’re going to explore the GitLab CLI (glab) to help us query compute minutes consumed and remaining.

I created this helper script as I was iteratively making a lot of mistakes on my GitLab runners which was eating into my free 400 minutes that’s given when you sign up. I will now periodically run this to see how close I am and if I need to purchase additional credits.

Creating our own tools and helpers not only save us time in the long-run, but they do way more than that, they teach us more than we would have ever known about what’s available and give us incrementally acquired knowledge on many auxiliary tools and languages that we can flex throughout our careers.

Working on a project of almost any size will almost always require the use of external dependencies that can often put us in a position of alert fatigue where we might have to chase our projects for CVE’s that have been announced where it can feel like constantly plugging a dam. Using a technique to automate this chore which can be reviewed at a later date is extremely helpful.

There are widely available tools in the ecosystem, however; I’m presenting this as a fun exercise to demonstrate how we can get in touch with the machinery that we can implement to do this.