DEV Community

Hoa Nguyen
Hoa Nguyen

Posted on Fully Autonomous

Asking my CI "why did it fail?" — a Jenkins connector for cognee

#ai #jenkins #opensource #hacktoberfest

Hacktoberfest: Contribution Chronicles

I'm a developer from Vietnam, and this is my contribution to WeMakeDevs Mergetober: a new data-source connector for cognee.

The problem

When a Jenkins build fails, the reason is usually a few lines at the bottom of a long console log.
A week later nobody remembers which job broke, or why.

I wanted to ask my CI a plain question — "which build failed last night, and why?" — and get an
answer with the exact error line.

What I built

A Jenkins data-source connector for cognee, an open-source
AI memory engine. It syncs Jenkins jobs and builds into cognee so you can search them in plain language.

It stores one record per job and one per build: result, time, duration, what started it, and for
failed builds the end of the console log.

How it works

  • Small API calls. Every request to Jenkins asks only for the fields it needs (tree=), so a big Jenkins server never sends its whole object graph. Logs are streamed and only the last 64 KB is kept.
  • Incremental sync. For each job it remembers the highest build number it has ingested. The next run only fetches newer builds. A build that is still running is skipped until it finishes.
  • Forget on delete. If you delete a job, or Jenkins discards old builds, the next sync removes them from cognee's memory too.
  • Careful by default. If a sync suddenly sees zero jobs, it deletes nothing (that is more likely a wrong folder or a permission problem than a real wipe). Values that look like secrets in logs (DEPLOY_TOKEN=…, password: …) are masked, and parameter default values are never read.

Trying it on a real Jenkins

I ran Jenkins locally in Docker with three small jobs: one that passes, one in a folder, and a
"nightly deploy" that fails and prints a fake token on purpose.

Jenkins dashboard with a failing nightly-deploy job

The failed build's console log, including a fake DEPLOY_TOKEN

Then I synced it into cognee and asked what failed. The answer named the job and the exact error,
and the stored log shows the token masked:

cognee answers: nightly-deploy failed with

Next I deleted nightly-deploy in Jenkins and synced again. The connector sent three deletions (the
job and its two builds), and cognee no longer knew about the failure:

After deleting the job:

What surprised me

  • The unit tests passed, but the first run against a real Jenkins showed that DEPLOY_TOKEN=supersecret123 was not masked: the check only matched the word token on its own, not inside a name like DEPLOY_TOKEN or AWS_SECRET_ACCESS_KEY. I fixed it and added a test. Testing against the real thing was worth it.
  • Asking cognee the exact same question twice can return a cached answer, so to check that the deleted job was really forgotten I asked a differently worded question.

How I worked

I used Claude Code as a coding assistant to write and test the connector, and I reviewed the code
before opening the PR. The tests and the local Jenkins check above are part of the PR description.

Try it 

docker run --rm -p 8080:8080 jenkins/jenkins:lts-jdk21
Enter fullscreen mode Exit fullscreen mode

Then follow the README in packages/connector/jenkins/ of the PR.

Feedback on the PR is very welcome.

Top comments (0)