Learning to Automate My Side Projects with SWE-agent + GitLab

I wanted to share something I built. I managed to connect SWE-agent with my self-hosted GitLab so that Issues can drive automation—and I think it’s kind of cool. (Currently, it isn’t directly supported in SWE-Agent, but there is an issue (https://github.com/SWE-agent/SWE-agent/issues/760) on GitHub to add support. Why wait? ^_^)


I’ve been tinkering with SWE-agent in the homelab while between roles. SWE-agent doesn’t natively support GitLab, but that wasn’t going to stop me—I wired it into my self-hosted GitLab instance so Issues drive the automation end-to-end.

The Flow I Built

1. Start with an Issue.
When I create an Issue, I describe the task in plain language. For example: “create `/taylor-swift` route that responds with JSON key lucky=13.”

2. Label the intent.
Add the label `run:swe` and tag the model (in my case: `model:qwen3-coder-30b-a3b-instruct` from LM Studio). There is also a label swe:in-progress so that the pipeline does not pick up in-progress issues. If the pipeline needs to be rerun for any reason, simply remove the in-progress label, and the pipeline will resume later.

3. Pipeline picks it up.
A scheduled GitLab CI pipeline looks for Issues with that label. The Issue description becomes the SWE-agent task body. ( right now it kicks off hourly, but this could be tuned to either kick off more often and exit fast if no tasks, or have it kick off based on an action, more digging required)


4. SWE-agent does the work.
It makes scoped edits, runs tests, and commits to a dedicated Issue branch (`swe-agent/issue-42`).




5. Merge Request creation is last.
Only once changes are done does the agent create or update a Merge Request for review.

After merging, continue onto the remaining steps of CI pipeline (For me that is currently just build and deploy to k8s)


Why Build This?

GitLab isn’t natively supported, but most of my projects run here. I wanted:
- Automation that respects GitOps workflows.
- Control and transparency over when MRs are created.
- A setup I could run fully self-hosted in homelab.

Now I’ve got it—and it feels powerful. Issues drive the whole thing, MRs are the destination, and the glue is just a GitLab CI pipeline with SWE-agent running inside.

Closing Thought

It’s about a repeatable pattern:
Declarative intent in Issues → agentic automation → controlled MRs.
It’s predictable, reviewable, and works with the GitLab workflows I already use.

Future Additions/Further work

  • I plan to explore incorporating unit tests into the swe-agent loop, so it identifies issues prior to attempting to merge. 

  • Improve the finish indicator description for the job so the llm knows its done (Currently there are on average 50 steps of swe agent saying it is completed the task (after push/mr created) before the ci job actually shuts down with succeeded)

  • Look at security concerns

  • Make it more general (exposing the model controls without changing the swe-agent ci job code)

This is a first pass to demonstrate that it works. If there is any interest, I’ll do a deeper dive into the gitlab-ci.yml that makes it all work.

P.S If anyone needs a human software engineer, let me know!

Taylor Swift Quote

“I wanna be defined by the things that I love, not the things I hate, not the things I’m afraid of, not the things that haunt me in the middle of the night. I just think that you are what you love.”

#gitlab #ci #devops #automation #swe #homelab #selfhosted #agenticautomation

Comments

Post a Comment

Popular posts from this blog

Ship-Ready Web Essentials: Search, Sitemap, Metadata & Icons (SvelteKit)

This guide is a pragmatic, production-minded checklist and how-to for hardening a SvelteKit landing site so it’s discoverable by search engines, understandable by AI crawlers, and delightful on modern devices. It includes file locations, example contents, and verification steps. Everything here works even if you only have a single landing page today. Branding note: this document uses a fictional brand (“Example Store”) and domain (example.com). Replace these with your own values when you implement. Quick To-Do Checklist • Serve a real XML sitemap at /sitemap.xml and reference it in robots.txt. • Add a lightweight, server-rendered /search?q=… endpoint (backs JSON-LD SearchAction). • Place ai.txt (allow/deny AI crawlers) and .well-known/security.txt (vuln-reporting). • Wire canonical Open Graph/Twitter tags and og.png for social previews. • Add platform icons (apple-touch-icon.png, safari-pinned-tab.svg) and site.webmanifest. • Harden app.html with meta theme-color (light/dark), color-sc...
Read more

Kubernetes Secrets Management — SOPS + age (GitOps‑friendly)

Image
  Owner: Platform Engineering Audience: Devs & Ops Status: Adopted This document captures the exact process we use to manage Kubernetes secrets with Mozilla SOPS and the age encryption tool. It includes why we chose this approach, how to work with secrets day‑to‑day, and trade‑offs versus other methods. Executive Summary We store Kubernetes Secret manifests in Git encrypted at rest using SOPS with an age public key.  SOPS encrypts your secret values with AES‑256‑GCM , which is industry gold standard. In SOPS you can not swap AES‑256‑GCM out. The age private key lives only in protected CI variables. CI decrypts the manifests at deploy time and applies them with kubectl. No in‑cluster controllers, CRDs, or webhooks are required. Why this approach Top benefits: • Zero in‑cluster installs (no CRDs/controllers to run or break). • GitOps‑native: encrypted YAML sits in the repo; diffs remain readable (metadata & keys stay visible). • Cloud‑agnostic: age works anywhere; no ...
Read more