DEV Community: Brett Ryan

Wabe Labs Is Born, and Building With Blueprints

Brett Ryan — Thu, 10 Sep 2026 05:07:14 +0000

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?"

If you've been following along, you know that I value structure. My development usually revolves around a folder structure on my laptop (~/Develop/${company}/${project}), and for years I used drunkendev for my personal projects, my original (un)professional handle. For this, I wanted a mature placeholder so had been using new-biz.

For creating individual project names, I looked back to a tool I wrote years ago that generated secure passwords by pulling random words from Lewis Carroll’s Alice in Wonderland texts. It would generate some quirky password combinations and is fondly remembered for making people laugh. I was using this method to define names, with the help of AI I would ask "Could you suggest some names for a core software engine using words from Lewis Carroll's Alice in Wonderland books?"

From this method, I codenamed my central project project-wabe. From then on, when I queried Gemini Notebook for architectural advice, it referenced "wabe" in its responses "within wabe you..." After bouncing the concept off a group of former colleagues and receiving positive feedback, the choice was clear.

In Through the Looking-Glass, wabe refers to the grass-plot surrounding a sundial, so called because it extends a long way before it, behind it, and on each side. For us, it represents the ideal architectural metaphor: defining the clear space and precise boundaries around modern software systems. You can read the full story on our Behind the Name page.

Securing the Digital Real Estate

With the name chosen, the immediate next step was securing the online footprint. Fortunately, wabelabs.com was available at retail pricing, so I secured it immediately after a quick name availability check in Australia. Once the business registration was finalised, I also purchased wabelabs.com.au to be used as a redirect back to our main site.

Making it Official

To make the brand official, I activated a sole-trader Australian Business Number (ABN) and registered the business name through ASIC.

Having secured the name I thought "Should I update my license headers from Brett Anthony Ryan?" I did a bit of sleuthing and learned a valuable legal lesson. As a sole trader, the business name is an operational identifier rather than a separate legal entity (which only comes with full incorporation as a Pty Ltd). For now, my personal name remains the contracting entity for my licenses and agreements, making this step both an operational milestone and a reality check on pre-incorporation setup.

While it's true this is a simple step, completing this registration was a psychological turning point. Before taking the leap, there was always a lingering question: "Am I really going to become a founder?" Securing the name was a concrete declaration of commitment: This is it, I'm doing it. It shifted my mindset from "I'm attempting it" to "I'm doing it".

With the name established, I created the Wabe Labs LinkedIn page, published an elegant landing page on wabelabs.com, and launched the Behind the Name feature content.

Financial Discipline from Day One

As I prepared my personal taxes for the end of FY26, it prompted me to think about establishing financial operations for Wabe Labs.

So I set to, and built a structured Google Sheets workbook tracking income, expenses, and a stacked ledger with standardised file-naming patterns for instant cross-referencing. Opening a dedicated business bank account completely separated my personal and business finances.

I have since run this setup by my accountant for review; having clean, audit-ready records from week three will make tax compliance and financial reporting effortless down the line.

Practicing Documentation-as-a-Contract

In my previous post, I detailed our Documentation-as-a-Contract AI Advisor Network, our strategy for establishing boundaries, using AI as an architectural advisor rather than a code generator. For this past week I really put this philosophy to the test while architecting what will become the core functional component that makes up our offering.

My exercise was to explore the best format for structured Mermaid diagrams for optimal AI context parsing. By loading Mermaid documentation alongside our project requirements into Gemini Notebook, I established a constrained, high-fidelity context window.

Through my interactions I got the warm and fuzzies as I realised, everything I've been preaching about creating constrained context windows for AI's created a precise hyper-focussed interaction that gives a much higher quality output. I had the feedback-loop model proved to be working as I iterated on my documentation.

What emerged was a project that ticked all the boxes I was after:

API Contracts (API.md): a project wabe-api-contract houses the external view of the projects gRPC and Protobuf service definitions that are published to my maven repository with java bindings. Auto-generated by protoc-gen-doc.
API Interface: Pure Java interfaces and records defining immutable domain schemas. Right now, this isn't auto-generated, but the other way around; it's all been defined in my README.md that I used to create the project, and I may lift the UML documents into this document.
API Bridge: Performing the bindings between model representation and wire representation, no project will need to do this on its own. Keeping it out of interface meant that interface remains pure, and keeping it out of contracts means that contracts has no transient dependency on the java records and interfaces.

Pulling this together felt extremely satisfying. In a world where so many are getting AI to generate code for them, I'm taking a completely different approach that may seem strange and less efficient, but I argue, that right now, I know exactly what my software is doing, how it's structured, and that structure came directly from me. I definitely used help, but the AI was helping me, not me instructing the AI.

Where to Next?

Now that my foundations are stable, I'm left to concentrate on the build of my core project Gyre: our feature execution engine.

It's still funny thinking about it. All my career I've worked inside an established enterprise building with networks, VPN's with cloud providers wired in a hub-and-spoke architecture. Now, I'm starting with a clean slate, exploring how to build that brick and mortar foundation myself.

As I think about how I might interact with Gyre running in my cloud environment, I think "Will I need to set-up an AWS Client VPN and Route 53?" Knowing that this can have a minimum cost of $100 a month, I'm looking for cheaper alternatives, and I think I might have discovered that with my current VPN provider, I might have a way with NordVPN's Meshnet to be able to provide this same capability for only a few dollars of additional AWS components.

Mind Discipline: Why Our AI Advisor Only Reads Hand-Crafted Contracts

Brett Ryan — Fri, 28 Aug 2026 03:12:04 +0000

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.

For years, I had been building a comprehensive repository of system architecture, design decisions, and guidelines on Confluence. It was my digital home. So, knowing I would be creating a startup, I set to work writing my documentation in my spare time in preparation. But during a brief hiatus of inactivity, the space was silently, unceremoniously deleted. It was gone. Late nights of ideas, patterns, templates, and reference materials vanished into the cloud ether.

That loss was a violent reminder of a lesson I thought I'd fully mastered: if your documentation doesn't live alongside your code, you don't truly own it. Relying on third-party SaaS wikis to store the soul of your system architecture is just another form of "click-ops". It creates an artificial separation between the craftsmen writing the logic and the documentation that defines it.

But rather than mourning my lost Confluence space, I treated it as a catalyst. I decided that our young startup would not have a bloated, detached corporate wiki. Instead, we would treat Documentation as a Contract - a unified, git-backed human-and-machine contract that serves as the precise, zero-maintenance boundary for our AI systems.

Here is how losing my documentation led to a new architectural philosophy, and how we built a zero-overhead, "Anti-AI AI Strategy" that uses GitLab CI/CD and Google Workspace to run a secure, managed RAG pipeline.

The Anti-AI Strategy: Why We Refuse to Let AI Write Our Code

Walk into almost any tech startup today, and you’ll find developers blindly feeding raw codebases into LLMs, asking them to write entire features from scratch. The result is a flood of low-effort, AI-generated slop, code that looks functional on the surface but lacks architectural cohesion, contains silent regressions, and strips away the engineering "fingerprint" of the creator.

We refuse to work that way.

To scale with pride and precision, our engineering philosophy is built on a simple premise: human intent over AI generation. Great software is a work of hand-crafted art. The code is merely an implementation detail, a reflection of the craftsman's pride. It's so much fun when you hear a peer say "I just read your git-commit and it made me laugh".

We do not use AI as a quick syntax completion engine or a mindless pull-request generator. Instead, we treat AI as a Principal Architect and Advisor. It is our sparring partner for system design, edge case validation, and macro-architecture. But if the AI is to be an effective advisor, it needs clean, high-fidelity context. Feeding it a massive, messy codebase results in noisy context, token bloat, and tactical code generation instead of strategic guidance.

This is where the concept of Documentation-as-Contract comes in.

Before a single line of business logic is written, the engineer must define the boundaries of the component. They do this by drafting several markdown files directly within the project's repository:

README.md: Describes the component’s internal mechanisms, local setup, and core intent. It explains the why and the how for human engineers.
INTERFACE.md: Describes the public-facing boundaries. This includes the public-facing code interfaces (interfaces, abstract classes, records).
API.md: Describes exposed ReST endpoints, gRPC/Protobuf contracts, GraphQL schemas.
Any other content may be produced that may add or separate boundaries. For example, USAGE.md might make more sense in some cases than creating a massive README.md
Infrastructure as Code may also live in infra/README.md as appropriate.

This documentation is the source of truth. If a public endpoint or module contract isn't documented in the API.md file or the interface contracts are not exposed in INTERFACE.md, then as far as the rest of the system (and our AI advisor) is concerned, it does not exist. By forcing ourselves to write the interface first, we ensure deep clarity of thought before code execution. I've said it so many times to peers - If you can't explain the contract clearly in text, the code behind it is probably too complex, or worse, it's not fully understood.

The Two-Tiered Context Architecture (Zero-Maintenance RAG)

You've probably seen the posts on Linkedin before, "How I used AI to create a RAG with 10 different pipeline components". It doesn't need to be so complex, and; you can do it with ease.

I originally subscribed to a Google Workspaces Business account just so I could get guaranteed private conversation history with Google Gemini, but then I started using Gemini Notebook (formerly NotebookLM). You can create a precise context window by adding just the sources you need when you interact. Either direct web sources, or; documents directly from Google Drive which auto-update as the document updates.

This prompted me the idea "Can I load my git-project documentation loaded to google workspaces as part of my CI/CD process?" This is where I took my concept of Documentation as a Contract and applied it directly to my AI strategy.

As part of this journey I set out a topology that centralises on a shared Google Workspace Drive called "Architecture". The primary consumer of this is my AI tools (Gemini Notebook), if it exists in the company, documentation must be stored here to back it. This is the knowledge repository, structured under automated folders mirroring the Gitlab project group path, and files named with the project embedded in them - this was a small lesson early on as it was hard to search, and differentiate sources when they all say README.md within Google Drive.

AI context is now surgically selected for each interaction by the author, they will select related components, either their API.md or INTERFACE.md depending on their interaction patterns, and may select relevant README.md for components that the AI needs a deeper understanding - maybe they are working on that component.

This approach allows Gemini to behave as both an architectural advisor and a project specialist for a given interaction. Since the author is selecting the precise components required - which are auto-updated, they get clear context with no overload and zero risk of the AI getting bogged down in needing to interpret low-level code.

Enter `wabe-tools`: Automating the Pipeline with Zero Overhead

With a separation of concerns in-place, without closing the automation loop, it would fail. This is why I created a small script to turn a Markdown file into a native gdoc file and have it uploaded to Google Drive. Combining this with a Gitlab component that can be included in any project to upload the documentation and we've completely closed the loop from architect to developer and back to our AI advisor network.

`md2gdoc`: The Google Cloud Document Loader

Firstly I needed a way to get content into google docs. They didn't have to be beautiful, but good enough for Gemini to get full context. I spent a day writing a python script with the following key requirements:

Must create a native Google Document file (gdoc)
Must create paths within Google Drive to the document
Must be able to specify a shared drive.

This is where the tool comes to the following contract.

md2gdoc [-h] [--title TITLE] [--drive DRIVE] [--folder FOLDER] file`

Parameter	Description
`file`	Path to input Markdown/Text file
`--title TITLE`	Title for the Google Doc
`--drive DRIVE`	Drive name to upload to.
`--folder FOLDER`	Folder path within drive.

It turns out that if you send a text file to Google Drive with the mimeType set to application/vnd.google-apps.document, the API automatically creates the google document and fills it with the text you pass, though; I am using gravitas-md2gdocs for basic formatting.

`publish-docs`: Gitlab Component to Close the Loop

Tying it all together is a Gitlab component that when included in a .gitlab-ci.yml pipeline will execute md2gdocs for each of the supplied documents. Sane defaults already look for the README.md file, but these may also be overridden.

Inputs

Inputs can be provided at the root and override-able at document item levels. Defaults are defined for our company documentation best practices that have been designed for our Gemini Notebook integration.

Input	Description
`stage`	Pipeline stage to run job in.
`drive`	Target Google Shared Drive name.
`folder`	Target folder path in Drive.
`docs`	JSON string array of document objects.
`docs.file`	File to be sent to google drive.
`docs.title`	Google document title.
`docs.full_title`	Allows providing a title that does not include the project name.
`docs.drive`	Item level drive override.
`docs.folder`	Item level folder override.

Usage

For a minimal implementation that publishes your project's README.md to our central Architecture as Components/$CI_PROJECT_PATH/$CI_PROJECT_NAME :: README, the following default configuration satisfies this requirement for most projects.

include:
  - component: $CI_SERVER_FQDN/my-group/wabe-tools/publish-docs@main

`infra-bootstrap-gcp`: Granting Projects to Publish Documentation

From the get-go, I knew I wanted to be able to send documentation directly from my laptop for testing purposes, but more importantly, I wanted this to be executed directly from my CI/CD pipeline. This is where I came up with the infrastructure required to grant individual projects and/or Gitlab groups Attribute Based Access Control (ABAC) least privileged to Google's API's via OpenID Connect (OIDC).

Temporary friction gives the calluses to be stronger!

It's at this point where I felt friction with the Google Cloud API's and Identity and Access management (IAM) differences between Amazon Web Services (AWS) a point of friction, though; having been through it has given me broader understanding that will help me later.

Demonstrating the same Documentation-as-Contract standards here, the following is an extract of the inputs/outputs from the infra-bootstrap-gcp OpenTofu inputs/outputs section:

Inputs

Name	Description
`input_gitlab_group_ids`	List of groups that are granted access. Note: this is a direct ancestor to a project and ancestors of a direct group to a project are not supported.
`input_gitlab_project_ids`	List of projects that are allowed access to write documents.
`input_gitlab_root_project_path`	Path prefix for projects
`input_gitlab_url`	GitLab URL used for the gitlab audience policy statement

Outputs

Name	Description
`google_organisation_id`	n/a
`output_google_pool_provider_name`	Google Pool provider name used for the audience. GCP_WORKLOAD_IDENTITY_PROVIDER is to be populated with this value in the Gitlab CI/CD module which will create an audience that contains this value.
`output_google_project_id`	n/a
`output_google_project_number`	n/a
`output_google_service_account_email`	Google Service account the Gitlab CI/CD module will use to impersonate requests. GCP_SERVICE_ACCOUNT_EMAIL is to be populated with this value.

The Documentation-as-Contract Pillars for AI and Humans

Combining principals of Documentation as Code, Contract-Driven Development and Context Window Engineering, we have established the 5 pillars that make up this framework:

Documentation is the Source of Truth: Code becomes a downstream implementation of a well-defined written design. If it isn't documented it doesn't exist.
Zero Context Overload: Surgically tailored context windows for our AI, maximising the quality of Gemini’s strategic advice.
CI/CD-Driven Architecture: We establish trust by providing the tools to ensure that documentation adjacent to code, is sent to our centralised documentation store only when code piplines succeed.
Prototyping Without Code: We can write, refine, and merge documentation first to validate an architectural idea or prototype before committing resources to build it.
Plumbing Code Auto-Documentation: For repetitive plumbing (like Terraform configurations), we use GitLab components like terraform-docs to auto-generate markdown files from code. This reverses the contract for the mundane, ensuring the plumbing documentation is always perfectly in sync.

RAD is a Discipline, Not a Luxury Suite

Many believe that Rapid Application Development (RAD) requires expensive enterprise software suites (Confluence, Jira, dedicated RAG search providers). Even I was fooled by my corporate discipline instilled in me over my career. With some forethought and discipline, you can build world-class developer experiences that are secure and scalable.

Today my company's tech stack consists of AWS as my primary cloud provider serving the content you're likely reading from AWS CloudFront, a Google Workspaces integration with Google Drive and Gemini+Notebook, Gitlab CI/CD to stitch it all together and strict disciplines with a focus on repeatability such as Infrastructure as Code (IaC) and company tooling. I completely own the IP with a low cost of ownership. The highest hitter being my Google Workspaces license which is still reasonable.

Where to From Here?

With my tooling in place, my deployment pipelines running, and our core strategy solidified, I am finally ready to start building the heart of the business.

As I begin writing our first services, my guiding architectural principle will be local-first, cloud-agnostic development. I want our applications to run flawlessly on a laptop with zero external dependencies, leveraging cloud-native features through clean facades and interfaces.

This is where the twin rails of the last two weeks come together:

rig will ensure that any developer tool, framework or cloud component needed for local-first development is instantly provisioned and standard across our environments with a single command.
publish-docs will ensure that as we design our components, boundary contracts (INTERFACE.md and API.md) are immediately pushed to our central Workspace, allowing Gemini to act as our strategic sounding board for the next engineering phase.

As central components, these will evolve over time, strengthening our base as we move forward.

In my next post, I will share the journey of developing to contracts allows one to continue to be productive even if not connected to the internet, by utilising a local first testing and development strategy and share my continued story of the Documentation-as-a-Contract for our AI advisor.

The Software Craftsman’s Day One: Why My First Week of Startup Life Had No Business Logic

Brett Ryan — Mon, 24 Aug 2026 04:22:26 +0000

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.

But my own discipline over the years took over - true craftsmanship rejects the illusion of hurried progress.

Years ago, I learned a fundamental lesson in cloud architecture: refuse click-ops and always rely on Infrastructure as Code (IaC) as your source of truth. Clicking through console windows to provision a database, where you instantly forget the exact steps you just took, builds technical debt that cannot be tracked, audited, or most crucially, reliably reproduced.

I had actually meant to start one week prior, but as I received my refurbished laptop, there was an issue that meant I needed to return the machine for repair. This meant I had to wipe it and wait over a week for repairs.

This taught me something: why not apply the same discipline of IaC to your own local environment? If "click-ops" is a sin in the cloud, then clicking through manual installers and executing rogue brew commands should be too.

To scale with pride and precision, I spent my first week doing something counter-intuitive. I created a tool and ecosystem that separates the hardware from the environment using IaC principles - designed to be liberating, not confining.

The Onboarding Tax: How KT Nightmares Led to Local IaC

The conviction to spend my first week writing zero business logic didn't come from a standard practice or theoretical textbook; it was forged in the exhausting final four months of my previous corporate role.

My final four months was an exhausting Knowledge Transfer (KT) to an incoming team. They were talented engineers, but they had never worked within our company let alone our specific environment, and none of the legacy team would be remaining to guide them. I found myself trying to condense ten years of deep, institutional system knowledge into a compressed onboarding window.

But the real bottleneck wasn’t teaching them our system design, it was the developer laptop environment.

On paper, a new developer could get "up and running" in about a week. But that was a surface-layer illusion. For months afterward, they would constantly hit silent road-blocks. I’d find myself saying, "Oh, you need to configure your SSH config this way," or "Right, you need this custom script to establish an AWS SSM tunnel to bypass that gateway."

Onboarding wasn't a single event; it was a slow, manual drip-feed of wiki pages, legacy scripts, and tribal knowledge. It was "wiki-ops" at its worst. What should have taken minutes took weeks, dragging down both the new engineers and the peers who had to constantly stop their own work to debug a local path.

Enter `rig`: A Blueprint, Not a Cage

To solve this onboarding tax permanently, I spent my first several days crafting rig.

Named after the nautical verb to equip a vessel with sails, standing tackle, and running gear - rig is a lightweight, POSIX-compliant developer toolchain dispatcher and provisioning system. To ensure it runs everywhere without dependency hell, it is built strictly for /bin/sh. This means it executes with zero pre-requisites across macOS, Linux distributions, and even within CI/CD runners.

It doesn't support Linux, yet!

While fully ready for Linux, without a functioning Linux system, I haven't yet tested it on Linux, and some of the scripts such as brew haven't been configured with the different Linux distributions in mind, yet.

Instead of a chaotic series of manual installers, setting up a new machine with our corporate standard is now a two-step process:

# Clone the repository
git clone https://github.com/your-user/rig.git
cd rig && ./rig install

Once executed, rig injects a single clean hook into your shell profile (.zshrc or .bashrc), marked clearly by # rig-tools:

eval "$("/path/to/rig-tools/rig" env)" # rig-tools

This single line evaluates a returned environment dynamically, allowing our developer tooling to evolve over time without having to re-install profile scripts.

You might ask: Why not just use an industry-standard configuration manager like Chef or Puppet?

In the enterprise space, tools like Chef or Puppet are often used to force compliance. They lock developers in a sterile box, dictating exactly how local machines must behave. It is an authoritarian approach to Developer Experience (DX) that strips away engineering personality and, frankly, makes talented developers want to quit.

I wanted a tool that was elective, not prescriptive.

By leveraging a modular domain architecture (separating language runtimes from tools) and adhering strictly to XDG configuration standards (storing persistent, non-clobbering key-value states in ~/.config/rig/config), rig acts as a launchpad, not a straightjacket. It guarantees every developer shares a baseline, reliable environment for our company's projects, while leaving them completely free to customise their editors, local paths, and shells.

# rig doctor ensures the environment hasn't drifted
rig doctor

# Modular updates for languages and tools
rig update
rig lang java
rig tool vim obsidian

We have turned what used to be weeks of peer-assisted debugging into a background task that takes minutes. If my laptop hardware fails tomorrow, I don’t face a week of downtime. I get a replacement machine, run rig install, and I am back to writing code in under five minutes.

Combine this with my standard rule "If you didn't commit and push your code to a branch, you didn't work today", and we have an almost zero down-time developer productivity at the end of week 1.

Once installed, a developer now has a useful tool (rig), ready to help them perform tasks within the company. Its intended now that this will be extended for any repetitive tasks that I might find myself performing through my journey.

Usage: rig <command> [options]

Commands:
  install
      Initiate the install script for the current platform
  update
      Update installed packages and toolchains
  doctor
      Verify environment
  tool <-l|tool>
      Configure/Install provided tool.
      Use "rig tool -l" to list available tools.

      Current: 1password, aws, colima, gcloud, git, localstack, obsidian,
               orbstack, tmux, vim

  lang <-l|lang>
      Configure/Install provided language support.
      Use "rig lang -l" to list available languages

      Current: java
  env
      Print environment include for use in shell scripts.
      NOTE: This will be added by 'install' to your environment, e.g.
            eval "$("/home/your-name/devel/rig-tools/rig" env)"
  config [-n] <key> [new-value]
      Get the current value or update the existing value with [new-value] if
      provided. The '-n' flag when present will not clobber the existing value.
  help
      Show this help

Config Values

  SKIP_INCLUDE  When this setting is 'true' the install/update/doctor commands
                will not attempt to add to your env, any other value will or
                when missing is treated as false.

Where to From Here?

Using these same fundamental principals, I've now been working on centralising my documentation strategy to function as what I'm calling an "Anti-AI AI Strategy" - we value the human creativity, but empower the mind with the tools to perform their role.

In my next post, I'll be talking about how I created a general contract for software projects to be documentation-first that encourages pipelines to centralise documentation in a shared company Google Drive (Architecture) with the dual-purpose goal of humans being able to centrally read the documentation, and more crucially; give Gemini Notebook the ability to have precise context on what the actor is interacting with the notebook for.

Utility to Find Gitlab Credit Usage

Brett Ryan — Sun, 23 Aug 2026 01:40:20 +0000

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.

Once complete, the final output should look like the following

Current Date : 2026-05-25
Month Elapsed: 80%
Month Credits: 400

MONTH    CONSUMED  REMAINING  USAGE %
-----    --------  ---------  -------
2026-03       221        179      55%
2026-04       302         98      76%
2026-05       277        123      69%

Full Script

You can obtain a copy of the full script which has been published as a public GitLab snippet.

Disclaimer

Code snippets and scripts provided within this article are strictly for educational and informational purposes. This code is provided "as-is" without any express or implied warranties of any kind. Always review and test scripts in a safe, non-production environment before deployment. See License Note for details on licensing.

Dependencies

Usage of the scripts within this article use two tools that are staples of a GitLab DevOps engineer.

GNU Bash 4.0+ is required as a shell interpreter. While I do make efforts to use 3.2 compatibility for macOS systems that still use the older shell, I do have a modern 5.x shell that I may have missed some compatibility, and I would encourage you to at least use a modern shell.
jq is an extremely useful JSON parser tool that allows transforming, navigating and producing output from structured JSON content. This should be a staple of any engineer who works with JSON structures without the need to open up a dependent programming language other than a shell.
GitLab CLI (glab) provides an excellent Command Line Interface (CLI) to hosted and the cloud hosted GitLab platform. If you're a regular GitLab user, this should become a core part of your toolkit. NOTE: for those from a GitHub background, this can be thought of as the GitLab equivalent.

Platform Compatibility

While I personally use a macOS system with tooling provided by the MacPorts project to remain current, I make best efforts to try and be platform independent by using POSIX standards and attempts at portability so that these scripts can be used in CI/CD platforms that may be running GLU/Linux. That said I can miss something, please use your best efforts to look for compatibility issues before attempting to run in different environments.

Within this script one known portability is the difference in the BSD Date vs the GNU Date. The script artifact from this article takes this into account and makes an attempt to test the BSD version before the GNU version, you may choose to reverse this.

What's the Problem?

GitLab provides us with a screen that we can visually inspect our current and past usage history. You can find this by navigating to your group in your GitLab instance and looking under Settings → Usage Quotas and navigate to the "Pipelines" tab.

Using this ClickOps¹ approach to finding information requires us to manually navigate and inspect. We would like to script this so that we as developers can get this information directly in a human friendly way, and; potentially add this to our CI/CD pipeline that could report this after each build.

GitLab GraphQL

We will be using the GitLab GraphQL API to query our usage. One note on the GitLab documentation is a single-page huge document that contains the whole GraphQL documentation and for my system at least, takes a long time to load and searching is near impossible which made writing this article painful, your mileage may vary.

Git project directories influence authentication

As taken from glab api graphql --help:

If the current directory is a Git directory, uses the GitLab authenticated host in the current directory. Otherwise, gitlab.com will be used.

We will be using the Query.ciMinutesUsage to query our usage. We can test this now by performing a query against the group namespace with the following replacing 9999 with your group id:

How do I find my Group ID?

Within the GitLab UI, you can find your Group ID by navigating to your group, click the three dots to the top right next to the "Create Project" button and choosing "Copy group ID" where it will also be displayed.

glab api graphql -f query='{
  ciMinutesUsage(namespaceId: "gid://gitlab/Group/9999") {
    nodes {
      monthIso8601
      minutes
    }
  }
}'

Depending on if you have been using GitLab hosted runners, you should get something like the following:

{
  "data": {
    "ciMinutesUsage": {
      "nodes": [
        {
          "monthIso8601": "2026-05-01",
          "minutes": 266
        },
        {
          "monthIso8601": "2026-04-01",
          "minutes": 302
        },
        {
          "monthIso8601": "2026-03-01",
          "minutes": 221
        }
      ]
    }
  }
}

We could then put this in a script and call it a day, potentially doing basic manipulation to limit with 1, and grep for minutes and call it a day:

#!/usr/bin/env bash

gid=9999

glab api graphql --output ndjson -f query='{
  ciMinutesUsage(namespaceId: "gid://gitlab/Group/'$gid'", first: 1) {
    nodes {
      monthIso8601
      minutes
    }
  }
}' | jq -r '.data.ciMinutesUsage.nodes[].minutes'

Here we introduced the first query parameter where this GraphQL query supports pagination, we then used a basic jq script to extract the minutes attribute. Since we selected a limit of the first 1 record from GitLab, this will always be a single element.

Usage History

Showing the consumed capacity is good, but it doesn't tell us if we started consuming credits or, if that value is from the prior month. Let's look at using the jq command to format this as a table that has the date and the number of consumed credits for that month.

When we start to get to this sort of processing, I like to place the output of my command into a variable, and then use that variable to pass as the input to my jq command. This gives two benefits.

It's easier to read and reason about the output of a command and the input to the next command instead of relying on our cognitive capacity to recognise all those chained pipes.
We can debug the output by echoing it so we can see when something is going awry (as it eventually will), allowing us to solve much faster.

#!/usr/bin/env bash

gid=9999

req='{
  ciMinutesUsage(namespaceId: "gid://gitlab/Group/'$gid'") {
    nodes {
      monthIso8601
      minutes
    }
  }
}'
res="$(glab api graphql -f query="$req")"

# For debugging we can comment and un-comment as needed.
echo "req: $req"
echo "res: $(echo "$res" | jq)"

We can take advantage of the Format strings and escaping @tsv jq built-in which allows us to take an array of fields and turn it into a tab separated table of values with each array being represented on a new line.

echo $res | jq -r '
  .data.ciMinutesUsage.nodes |
    sort_by(.monthIso8601)[] |
    [.monthIso8601, .minutes] |
    @tsv')

This now produces a nice tab-separated-values table for each month. Note that I've also reversed the sort by adding an explicit sort on .monthIso8601.

2026-03-01  221
2026-04-01  302
2026-05-01  277

What is my Limit?

Having a listing of what's consumed is very helpful in its own right, though; it would be really helpful if we could also display how much we have available for use.

At the time of writing I could not find a GraphQL query that would return the credits available, but; I did find the glab api /namespaces/$gid gives us what we need:

DEFAULT_MONTH_CREDITS=400

ns_res=$(glab api /namespaces/$gid 2>/dev/null)
if [ -z "$ns_res" ]; then
  echo "Couldn't find credits, defaulting to $DEFAULT_MONTH_CREDITS"
  month_credits=$DEFAULT_MONTH_CREDITS
else
  echo $ns_res |jq >&2
  blim=$(echo $ns_res | jq -r '.shared_runners_minutes_limit // '$DEFAULT_MONTH_CREDITS)
  elim=$(echo $ns_res | jq -r '.extra_shared_runners_minutes_limit // 0')
  echo "Base: $blim, Extra: $elim"
  month_credits=$((blim + elim))
fi

This will first try to find what credits are associated, if returned the sum of shared_runners_minutes_limit + extra_shared_runners_minutes_limit if they are available. Note that we use the jq alternative operator which will return the left value if it's not null, otherwise defaults to the rightmost value.

How Many Credits Remain?

Now that we have the amount of credits consumed, and our credit limit; we can add a column to our table to show how many credits we have left for the month. This will show based on the current credit limit for the prior months.

We will alter our script to ensure that we find available credits before the history table.

DEFAULT_MONTH_CREDITS=400

# Find monthly credits
ns_res=$(glab api /namespaces/$gid 2>/dev/null)
if [ -z "$ns_res" ]; then
  echo "Couldn't find credits, defaulting to $DEFAULT_MONTH_CREDITS"
  month_credits=$DEFAULT_MONTH_CREDITS
else
  blim=$(echo $ns_res | jq -r '.shared_runners_minutes_limit // '$DEFAULT_MONTH_CREDITS)
  elim=$(echo $ns_res | jq -r '.extra_shared_runners_minutes_limit // 0')
  echo "Base: $blim, Extra: $elim"
  month_credits=$((blim + elim))
fi

# Build table of remainders
req='{
  ciMinutesUsage(namespaceId: "gid://gitlab/Group/'$gid'") {
    nodes {
      monthIso8601
      minutes
    }
  }
}'
res="$(glab api graphql -f query="$req")"

echo $res | jq -r '
  .data.ciMinutesUsage.nodes |
    sort_by(.monthIso8601)[] |
    ('$month_credits' - .minutes) as $remaining |
    [
      .monthIso8601,
      .minutes,
      $remaining
    ] | @tsv'

Now we will have an output similar to the following:

Base: 400, Extra: 0
2026-03-01  221 179
2026-04-01  302 98
2026-05-01  277 123

Note on passing values

Note that in order for us to pass the $month_credits variable value we had to close the quoted script and reopen after referring to the variable value. An alternative would have been to pass the variable as an argument to jq, though; pay attention that it must be converted tonumber in order to be used in math expressions.
data=$(echo $res | jq -r --arg credits "$month_credits" '
  .data.ciMinutesUsage.nodes |
    sort_by(.monthIso8601)[] |
    (($credits | tonumber) - .minutes) as $remaining |
    [
      .monthIso8601,
      .minutes,
      $remaining
    ] | @tsv')

For a nice effect, we can now add a percentage to our table:

data=$(echo $res | jq -r '
  .data.ciMinutesUsage.nodes |
    sort_by(.monthIso8601)[] |
    ('$month_credits' - .minutes) as $remaining |
    [
      .monthIso8601,
      .minutes,
      $remaining,
      ((100 * .minutes / '$month_credits' | round | tostring) + "%")
    ] | @tsv')

This will give us a table that contains consumed, remaining and a usage %. Now it would be nice to have headings on this table so we don't have to remember what each column represents.

In order to achieve this, we will update our script to contain two parts by using the comma operator and a constant array for all our headings:

data=$(echo $res | jq -r '
  (["MONTH", "CONSUMED", "REMAINING", "USAGE %"]),
  (
    .data.ciMinutesUsage.nodes |
      sort_by(.monthIso8601)[] |
      ('$month_credits' - .minutes) as $remaining |
      [
        .monthIso8601,
        .minutes,
        $remaining,
        ((100 * .minutes / '$month_credits' | round | tostring) + "%")
      ]
  ) | @tsv')

When you run this, you will now find the columns are not aligned with the output. We can fix this by using the column command.

echo "$data" | column -t -s $'\t'

The table doesn't look bad, though we might like to add underline separators from the heading to the data. To do this, we can use the comma operator again within the headings to split its output to the original value and repeat the - character for the length of the heading. In the following modification, note we use the identity to print the heading, then the comma operator, followed by a map(length | . * "-"). What this is doing is mapping the heading to the length number and multiplying with a string literal which results in the repeated character.

data=$(echo $res | jq -r '
  (["MONTH", "CONSUMED", "REMAINING", "USAGE %"] | (., map(length | . * "-"))),
  (
    .data.ciMinutesUsage.nodes |
      sort_by(.monthIso8601)[] |
      ('$month_credits' - .minutes) as $remaining |
      [
        .monthIso8601,
        .minutes,
        $remaining,
        ((100 * .minutes / '$month_credits' | round | tostring) + "%")
      ]
  ) | @tsv')

How Much of the Month has Passed?

While we now show percentage used, we could show a percentage of how far we are into the current month. This will allow us to visually see if we might be going over in the current month:

day="$(date +%e)"

days_in_month="$(date -v+1m -v1d -v-1d +%d)"
month_elapsed_pct="$((100 * day / days_in_month))"

echo "Current Date : $(date +%Y-%m-%d)"
echo "Month Elapsed: $month_elapsed_pct%"

This will work great, but; only on a BSD based system. The only way I could think to make this work for a GNU/Linux based system is to first fail with the BSD version and then try the GNU version:

day=$(date +%e)

if ! days_in_month=$(date -v+1m -v1d -v-1d +%d); then
  if ! days_in_month=$(date -d "$(date +%Y-%m-01 2>/dev/null) \
      +1 month -1 day" +%d 2>/dev/null); then
    echo "Could not determine find BSD or GNU compatible date command." >&2
    exit 3
  fi
fi
month_elapsed_pct=$((100 * day / days_in_month))

Tightening things up

While we have something fairly useful that we can call at any time, the script is still fairly basic, and requires us to hard code values. We can first look at moving all the logic to function blocks before adding command line options to manipulate the scripts behaviour.

Move Logic to Functions

While probably unnecessary for this script, it's a practice I like to do as it allows me to turn features on and off easily, or move call order around if I want the percentage of month elapsed to appear first for example.

GID=
MONTH_CREDITS=400
MONTHS=4

query_usage() {
  glab api graphql -f query='{
    ciMinutesUsage(namespaceId: "gid://gitlab/Group/'$1'", first: '$2') {
      nodes {
        monthIso8601
        minutes
      }
    }
  }'
}

find_credits() {
  local gid="$1"
  local credits="${2:-400}"
  local query_credits="${3:-0}"
  local ns_res elim blim

  if (( query_credits )); then
    echo -n "Querying limits... ">&2
    ns_res=$(glab api /namespaces/$gid 2>/dev/null)
    if [ -z "$ns_res" ]; then
      echo -e "Failed, falling back to defaults.\n" >&2
    else
      blim=$(echo $ns_res | jq -r '.shared_runners_minutes_limit // '$credits)
      elim=$(echo $ns_res | jq -r '.extra_shared_runners_minutes_limit // 0')
      echo -e "Base: $blim, Extra: $elim\n" >&2
      credits=$((blim + elim))
    fi
  fi
  echo $credits
}

show_month_elapsed() {
  local days_in_month month_elapsed_pct
  local day=$(date +%e)

  if ! days_in_month=$(date -v+1m -v1d -v-1d +%d); then
    if ! days_in_month=$(date -d "$(date +%Y-%m-01 2>/dev/null) +1 month -1 day" +%d 2>/dev/null); then
      echo "Could not determine find BSD or GNU compatible date command." >&2
      exit 3
    fi
  fi
  month_elapsed_pct=$((100 * day / days_in_month))

  echo "Current Date : $(date +%Y-%m-%d)"
  echo "Month Elapsed: $month_elapsed_pct%"
}

show_month_remaining() {
  local gid=$1
  local credits=$2
  api_res=$(query_usage $gid 1)
  res="$(echo "$api_res" | jq -r --arg credits "$credits" '
    .data.ciMinutesUsage.nodes |
      sort_by(.monthIso8601) |
      last |
      ($credits | tonumber) - .minutes
    ')"
  echo "$res"
}

show_usage_history() {
  local gid=$1
  local credits=$2
  local months=$3

  echo -e "Month Credits: $credits\n"

  api_res=$(query_usage $gid $months)
  res="$(echo "$api_res" | jq -r --arg credits "$credits" '
    # Helper function to pad strings for right alignment
    def lpad(n): tostring | ("          " + .) [-n:];

    (
      ["MONTH", "CONSUMED", "REMAINING", "USAGE %"] | (., map(length | . * "-"))
    ),
    (
      .data.ciMinutesUsage.nodes |
        sort_by(.monthIso8601)[] |
        ($credits | tonumber) as $credits |
        ($credits - .minutes) as $remaining |
        [
          (.monthIso8601 [:7]),
          (.minutes | lpad(8)),
          ($remaining | lpad(9)),
          ((100 * .minutes / $credits | round | tostring) + "%" | lpad(7))
        ]
    )
    | @tsv')"
  echo "$res" | column -t -s $'\t'
}

I've tightened these up a little with some preparation for enabling some command line options. Now we can call each of these as we need.

month_credits=$(find_credits "$GID" "$MONTH_CREDITS" 0)

echo "Remaining: $(show_month_remaining "$GID" "$month_credits")"
show_month_elapsed
show_usage_history "$GID" "$month_credits" "$MONTHS"

Adding Command Line Options

Now that we have a modular approach, we can add some command line options that the user can pass to manipulate the scripts behaviour. We will provide the following options, which; we might as well write out in a help function.

show_help() {
  echo "usage: $(basename "$0") [options]

  -h            : Show this help.
  -c <credits>  : Monthly credits (default: $MONTH_CREDITS)
  -q            : Query for monthly credits which will include purchased credits
  -g <gid>      : Group ID for usage summary
  -m <months>   : Months of history (default: $MONTHS)
  -r            : Only print the remaining minutes.
" >&2
}

For this we're going to set some global flags that the options will manipulate, and; we can set our global defaults. At the top of our script, lets set these values and enable strict mode while we're at it.

set -euo pipefail

MONTH_CREDITS=400
MONTHS=3
GID="9999"

IS_QUERY_CREDITS=0
IS_REMAINING_ONLY=0

While we're at it we can create some helper functions to ensure the user has passed correct integer values, and that the required glab and jq commands are made available:

require_cmd() {
  command -v $1 &>/dev/null || {
    echo "$1 is required for this script to function. See $2" >&2
    exit 1
  }
}

require_int() {
  if [[ ! "$1" =~ ^[0-9]+$ ]]; then
    echo "$2 must be a positive integer number" >&2
    show_help
    exit 2
  fi
  echo $1
}

This now enables us the power to put it all together and add the options parsing and validation behaviour before calling our logic.

while getopts hc:qg:m:r OPTION; do
  case $OPTION in
    h)  show_help
        exit 0 ;;
    c)  MONTH_CREDITS=$(require_int "$OPTARG" "credits") || exit 1 ;;
    q)  IS_QUERY_CREDITS=1 ;;
    g)  GID=$(require_int "$OPTARG" "group id") || exit 1 ;;
    m)  MONTHS=$(require_int "$OPTARG" "months") || exit 1 ;;
    r)  IS_REMAINING_ONLY=1 ;;
    \?) show_help >&2
        exit 1 ;;
  esac
done
shift $((OPTIND - 1))

# I'm keeping this here so -h works
require_cmd glab "https://docs.gitlab.com/cli/"
require_cmd jq "https://jqlang.org/"

month_credits=$(find_credits "$GID" "$MONTH_CREDITS" "$IS_QUERY_CREDITS")

if (( IS_REMAINING_ONLY )); then
  show_month_remaining "$GID" "$month_credits"
else
  show_month_elapsed
  show_usage_history "$GID" "$month_credits" "$MONTHS"
fi

Parting Thoughts

Over the years I've had the privilige to teach many newcomers, help others solve problems and am often asked "how do you know all this?". My will always reply with a sentiment that is shared with artists and musicians; we aren't born with it, what you don't see is the countless hours of us practicing, frustrated, excited, building up callouses late at night when nobody is watching. We developers in my eyes are artists of a different canvas, and we should hold pride in the work we do. When you have this mindset, your quality of output improves, you want to share it with others because of all the hard work you put into it.

Today while developers live in a world with Artificial Intelligence (AI), it can become easy for us to become complacent and rely on the AI which can rob us from skills that were so second nature to us that we wouldn't think about it when doing it. If we don't flex that muscle, it becomes weak to the point it can become painful to use. I encourage you to regularly flex those muscles by practicing with tools like these on your own projects.

License Note

This article is licensed under the Creative Commons Attribution 4.0 International license (CC BY 4.0) You are free to share, copy, and adapt this material, provided you give appropriate credit and link back to this original post. Any companion scripts featured in this article are distributed under the Apache License 2.0 and made available as snippets on my GitLab Profile.

ClickOps emerged organically within the DevOps community circa 2017–2019 as a tongue-in-cheek contrast to the disciplined Infrastructure-as-Code (IaC) which gained wide-spread adoption. ↩

Keeping Dependencies Current

Brett Ryan — Fri, 21 Aug 2026 13:50:41 +0000

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.

What we will do:

Use start.spring.io to create a simple project.
Configure pom project with specific dependency rules.
Create dependencies.sh script.
Add GitLab CI job to perform automatic dependency checks on a chore/version-updates branch.

Full Script

You can obtain a copy of the full script which has been published as a public GitLab snippet.

Create Your Project

Using the spring starter at start.spring.io, create a maven based project. As we're using the versions-maven-plugin we will require this to be a maven project.

You can use this template which is a bookmark of a spring 4.0.6 project using maven and JDK 26.

Configure Project to Ignore pre-releases

I've found that in maven central, some projects will release release candidates, milestones, alpha and other releases that I do not want to have my dependency management script to try an upgrade to. My original approach to solve this was to set the maven.version.ignore maven property to ignore these
patterns, like the following:

<properties>
  <maven.version.ignore>(?i).*[\-\.](m|rc|dev|alpha|beta)[\-\.]?[0-9]*</maven.version.ignore>
  <processDependencyManagementTransitive>${processDependencyManagementTransitive}</processDependencyManagementTransitive>
</properties>

This works well, however; if you want to have rules where you may want to be using pre-releases or milestones from specific vendors, i.e. you may be testing the newest spring milestones, you will need to extend this by adding a ruleSet to the build/plugins section of your pom.

<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>versions-maven-plugin</artifactId>
      <configuration>
        <ruleSet>
          <rules>
            <rule>
              <ignoreVersions>
                <ignoreVersion>
                  <type>regex</type>
                  <version>(?i).*<a href="m|rc|dev|alpha|beta">\-\.</a>[\-\.]?[0-9]*</version>
                </ignoreVersion>
              </ignoreVersions>
            </rule>
            <rule>
              <groupId>org.springframework.boot</groupId>
              <artifactId>spring-boot-starter-parent</artifactId>
            </rule>
            <rule>
              <groupId>org.springframework.modulith</groupId>
              <artifactId>spring-modulith-bom</artifactId>
            </rule>
          </rules>
        </ruleSet>
        <processDependencyManagementTransitive>${processDependencyManagementTransitive}</processDependencyManagementTransitive>
      </configuration>
    </plugin>
  </plugins>
</build>

Note that I've also set the property processDependencyManagementTransitive, keep this in your properties section as our script will set this later.

Dependency Update Script

We will now create a script that will perform the dependency update check and optionally perform a git commit if updates were found.

There are two sets of maven goals we could use

To show only:

versions:display-dependency-updates
versions:display-plugin-updates
versions:display-property-updates

Or, to perform the updates my modifying the pom.

versions:update-parent
versions:update-properties
versions:use-latest-versions

Refer to the versions-maven-plugin documentation for more on what these goals do.

We will write a script that gives us the following capabilities:

Usage: dependencies.sh [-cCsStu]

-c  : Perform git commit opening editor for review
-C  : Perform git commit
-s  : Don't perform snapshot updates
-S  : Force update snapshot updates
-t  : Process transitive dependencies
-u  : Perform update

For this script, we will begin with the setup and a getopts block that takes these command line arguments.

#!/usr/bin/env bash

goals="
  versions:display-dependency-updates
  versions:display-plugin-updates
  versions:display-property-updates
"

snaps=""
margs=""

while getopts cChsStu OPTION; do
  case $OPTION in
    h)  echo "
Usage: $0 [-cCsStu]

-c  : Perform git commit opening editor for review
-C  : Perform git commit
-s  : Don't perform snapshot updates
-S  : Force update snapshot updates
-t  : Process transitive dependencies
-u  : Perform update
" >&2
        exit 1
        ;;
    c)  commit_mode=edit ;;
    C)  commit_mode=perform ;;
    s)  snaps="-nsu" ;;
    S)  snaps="-U" ;;
    t)  margs="${margs} -DprocessDependencyManagementTransitive=true" ;;
    u)  goals="
          versions:update-parent
          versions:update-properties
          versions:use-latest-versions
        "
        ;;
  esac
done
shift $((OPTIND - 1))

This allows the user to either view (default) or update (-u). When viewing the caller can test for transitive dependency updates with -t. We can also commit changes automatically with -c to open an editor or have -C perform the commit.

In order to capture the dependencies that were updated, we will tee the output from maven (using ./mvnw here) to allow us to parse the content when complete.

mvn_log="$(mktemp)" || {
  echo "Couldn't create temp file" >&2
  exit 1
}
trap 'rm -f "$mvn_log"' EXIT

echo ./mvnw $snaps $margs $goals
./mvnw $snaps $margs $goals | tee $mvn_log

Here we will parse the output file to list off all our changes. A regular expression here formats the content into the following form:

- {{ DEPENDENCY }}: {{ FROM }} -> {{ TO }}

This format will strip out property managed versions such as ${spring-modulith.version} and replace it with spring-modulith to make our git commit more readable.

changes="$(
  grep "Updated " "$mvn_log"|\
    sed -E 's/^.* Updated (\$\{)?([^.}]*)(.version)?\}? from (.*) to (.*)$/- \2: \4 -> \5/')"

Regular Expression Deep Dive

We're creating an expression that looks for lines that have the following core pattern:

^.* Updated: Looks from the start of line until we reach the word Updated with a leading and trailing space.

(\$\{)?: May contain the sequence ${ which we want to ignore so must remember to skip this capture group.

([^.}]): Capture all characters that are not '.' or '}', there is a slight issue with this in that if you use a property that doesn't end in .version but does have a dot '.' in it's name, it might not be processed correctly.

(.version)?\}?: skip the optional phrase .version and the optional } character.

from (.*) to (.*)$ capture the from and to versions.

If all these sequences match the line, it will be replaced with the capture groups we are interested in - \2: \4 -> \5.

We can now test for this to see if there were any changes detected, if there are, we can then perform the determined git commit option chosen by the caller.

if [ -z "$changes" ]; then
  echo "No changes detected to commit."
else
  commit_msg="[chore] Dependency and plugin updates

$changes"

  echo -e "$commit_msg" > .git/COMMIT_EDITMSG
  if [ -z "$commit_mode" ]; then
    echo -e "\n --- Changes staged for commit ---"
  else
    echo -e "\n--- Committing Changes ---"
    git add pom.xml **/pom.xml 2>/dev/null
    if [ "$commit_mode" == "edit" ]; then
      git commit -m "$commit_msg" -e
    else
      git commit -m "$commit_msg"
    fi
  fi
fi

Setup GitLab Automation

This could now be setup on an automated chore/version-updates branch to be performed once a week or on a schedule of your choosing.

Configure your .gitlab-ci.yml with blocks similar to the following, your configuration may look different, however; in my case I use GraalVM CE edition for my use-cases.

.maven-base:
  image:
    name: ghcr.io/graalvm/jdk-community:25
    entrypoint: [""]
  cache:
    key: "maven-shared-cache"
    paths:
      - .m2/repository
      - .sonar/cache

version_updates:
  extends: .maven-base
  stage: test
  script: |
    microdnf install -y git

    git config --global user.name "GitLab CI Bot"
    git config --global user.email "brett.ryan+gitlab-bot@gmail.com"
    git remote set-url origin https://oauth2:${GITLAB_TOKEN}@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git

    ./dependencies.sh -u -C
    if [[ "$(git rev-list --count @{u}..HEAD)" != "0" ]]; then
      git pull origin ${CI_COMMIT_REF_NAME} --rebase
      git push origin HEAD:${CI_COMMIT_REF_NAME}
    fi

  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_BRANCH == "chore/version-updates"'
      when: always
    - when: never

GITLAB_TOKEN Best Practices

Ensure that you create a masked Group Access Token or Project Access Token for GITLAB_TOKEN. This token will need to have write_repository access.

In this script we take advantage of the script using the -C option to perform the automated commit, which; can then be detected with git rev-list --count @{u}..HEAD to detect if changes were made. If they were, then we can then push the commits.

Next Steps

There are several ways you could progress this by having full regression tests performed, notifications to slack or teams to notify the development team when the branch has been updated.

You could now integrate this into a release cycle where a QA manager performs validation and owns the chore branch, and; what should be done in the negative scenario where there may be versions that are not desired? Would you make it a practice to include them into the ruleSet? This could even be automated based on build failures.

DEV Community: Brett Ryan

Wabe Labs Is Born, and Building With Blueprints

We Have a Name: Wabe Labs

Securing the Digital Real Estate

Making it Official

Financial Discipline from Day One

Practicing Documentation-as-a-Contract

Where to Next?

Mind Discipline: Why Our AI Advisor Only Reads Hand-Crafted Contracts

The Anti-AI Strategy: Why We Refuse to Let AI Write Our Code

The Two-Tiered Context Architecture (Zero-Maintenance RAG)

Enter wabe-tools: Automating the Pipeline with Zero Overhead

md2gdoc: The Google Cloud Document Loader

publish-docs: Gitlab Component to Close the Loop

Inputs

Usage

infra-bootstrap-gcp: Granting Projects to Publish Documentation

Temporary friction gives the calluses to be stronger!

Inputs

Outputs

The Documentation-as-Contract Pillars for AI and Humans

RAD is a Discipline, Not a Luxury Suite

Where to From Here?

The Software Craftsman’s Day One: Why My First Week of Startup Life Had No Business Logic

The Onboarding Tax: How KT Nightmares Led to Local IaC

Enter rig: A Blueprint, Not a Cage

It doesn't support Linux, yet!

Where to From Here?

Utility to Find Gitlab Credit Usage

Full Script

Disclaimer

Dependencies

Platform Compatibility

What's the Problem?

GitLab GraphQL

Git project directories influence authentication

How do I find my Group ID?

Usage History

What is my Limit?

How Many Credits Remain?

Note on passing values

How Much of the Month has Passed?

Tightening things up

Move Logic to Functions

Adding Command Line Options

Parting Thoughts

License Note

Keeping Dependencies Current

Full Script

Create Your Project

Configure Project to Ignore pre-releases

Dependency Update Script

Regular Expression Deep Dive

Setup GitLab Automation

GITLAB_TOKEN Best Practices

Next Steps

Enter `wabe-tools`: Automating the Pipeline with Zero Overhead

`md2gdoc`: The Google Cloud Document Loader

`publish-docs`: Gitlab Component to Close the Loop

`infra-bootstrap-gcp`: Granting Projects to Publish Documentation

Enter `rig`: A Blueprint, Not a Cage