Fix My CI

Fix My CI — an AI agent that detects GitLab pipeline failures, reads the logs, finds the root cause, and opens a fix PR automatically. Less debugging, more shipping.

Comment

Inspiration

Every developer has lost hours staring at a red CI pipeline. You push your code, everything breaks, and suddenly your entire momentum is gone — you're copy-pasting error logs into Google, reading Stack Overflow threads from 2019, and making random changes hoping something sticks. I've been there too many times. The frustration isn't just the time lost — it's the context switching. You were building something, and now you're debugging infrastructure. I built Fix My CI because I wanted that time back.

What it does

Fix My CI is an AI agent that lives inside your CI/CD lifecycle. When a GitLab or GitHub pipeline fails, it automatically fetches the job logs, identifies the root cause, generates a minimal fix, and opens a Merge Request — without any human intervention. The developer gets a notification that their pipeline broke and a PR is already waiting for review. The average fix takes under 60 seconds.

Beyond just fixing pipelines, the agent also runs a security scan on every fix it generates — checking for vulnerable package versions and accidentally exposed secrets in logs — and a pipeline optimizer that suggests caching improvements, lighter base images, and parallelization opportunities.

How I built it

The backend is a FastAPI server with four core components working in sequence. A PipelineListener fetches job logs and the CI config from the GitLab or GitHub API the moment a webhook fires. A LogParser runs the logs through 13 known error patterns — dependency mismatches, missing packages, permission errors, auth failures — and resolves them instantly without any AI call. For unknown errors, a FixGenerator sends the logs and CI config to Google Gemini with a structured prompt that asks for a JSON response containing the fix, a confidence score, and a plain English explanation. Finally, GitLabAPI and GitHubAPI wrappers create a branch, commit the fix, and open the MR automatically.

The frontend is a vanilla HTML dashboard that polls the backend every 3 seconds, showing live pipeline status, agent workflow steps, diffs, security alerts, and optimization suggestions. Everything is persisted in SQLite so fix history and deduplication survive server restarts. The whole thing is deployed on Render.

Challenges I ran into

The first challenge was the spam problem — and I found out the hard way. In my first test, I pushed a broken pipeline and watched the agent work. What I didn't realize was that GitLab fires a webhook on every pipeline status update, not just the initial failure. The agent was receiving the same event over and over, running the fix each time, and opening a new MR on every single trigger. I woke up to 771 merge requests on my test repo. All saying "fix: auto CI fix [auto-fix]." All created within seconds of each other. It was equal parts horrifying and hilarious. I added a deduplication check that day — if a pipeline ID has already been processed, every subsequent webhook for that pipeline is silently ignored.

The second challenge was Python version compatibility on Render. The platform defaulted to Python 3.14, which broke pydantic-core during the build. I had to pin Python to 3.11 via a .python-version file and an environment variable.

The third was getting the LLM to return reliable structured output. Early prompts produced markdown explanations, partial JSON, or code blocks with no JSON at all. I rewrote the prompt to be extremely explicit — "respond ONLY with a JSON object, no preamble, no backticks, no explanation outside the JSON" — and added a fallback parser that strips code fences and handles plain text gracefully.

Accomplishments that I'm proud of

Getting the end-to-end flow working in a real environment — a genuine pipeline failure triggering a webhook, the agent analyzing it, and a real MR appearing in GitLab with the correct fix — felt genuinely magical the first time it worked. I'm also proud of the 13-pattern instant fix system, which means the most common CI failures never even reach the LLM and are resolved in under a second. The security scanner that checks every fix for CVEs and exposed secrets felt like a natural extension that makes the tool genuinely safer to use, not just faster.

What I learned

Webhooks are not fire-once events. GitLab sends multiple webhook calls for a single pipeline as it transitions through states, and any agent that acts on webhooks needs deduplication built in from day one — not added after 771 accidental merge requests. I also learned that LLM output formatting needs to be treated like an untrusted input — you have to write defensive parsers that handle every possible response format, not just the happy path. And deploying to Render taught me that "it works on my machine" still very much applies to Python version dependencies.

What's next for Fix My CI

The immediate next step is auto-retry — after the fix MR is merged, the agent triggers the pipeline again and reports whether it went green, completing the self-healing loop. After that, I want to add a Slack and Discord integration so teams get notified the moment a fix MR is opened, without needing to watch a dashboard. Longer term, the most interesting direction is multi-repo intelligence — if the same error pattern appears across different projects, the agent learns from the first fix and applies it instantly to every subsequent occurrence, turning a 60-second fix into a 0-second fix. I also want to expand beyond GitLab and GitHub to support Bitbucket and Jenkins, making Fix My CI the universal CI repair layer for any pipeline on any platform.

Built With

Share this project:

Updates