DEV Community: Daniel Chege

Asking my CI "why did that fail?": GitHub Actions cognee

Daniel Chege — Wed, 28 Oct 2026 13:03:46 +0000

I wanted to ask my CI a plain question: "which workflows failed recently, and why?" So I built a connector that turns GitHub Actions runs into memory an LLM can answer from.

The problem: CI history is hard to ask questions of

When a build goes red, finding out why means a lot of clicking. You open the Actions tab, pick a run, expand the failed job, then scroll a raw log full of timestamps and ANSI codes until you find the ##[error] line.

That works for one run. It breaks down when you want the pattern: is this the same test that failed last week? Which workflow keeps needing approval? What changed on main lately? The answers are spread over dozens of runs, and none of them are searchable together.

I ran into this myself while contributing to cognee-community from a fork. In its Actions tab, my runs sat alongside many others marked action_required, because workflows on fork PRs wait for a maintainer to approve them. Real failures were mixed in with those waiting runs, and the only way to tell them apart was to open each one.

What I built

I contributed a GitHub Actions data-source connector to cognee-community (PR #383). cognee is an open-source memory layer for AI apps: you add data, it builds a knowledge graph plus embeddings, and you query it in natural language.

The connector is a single function, github_actions_source(). You give it one or more owner/repo names, and it returns a dlt source that cognee can ingest directly. Each completed workflow run becomes one readable document. Failed runs can include a short summary of their log instead of the whole thing.

How it works

The connector does the tedious part: it reads the API, trims the logs and writes each run up as markdown. cognee does the rest.

Here is the real document for the failed bump run from the demo below. Its whole failure log comes down to two error lines:

Repository: topoteretes/cognee-community
Workflow: automation | Bump cognee in the database adapters (.github/workflows/bump_cognee.yml)
Run: #22, attempt 1
Conclusion: failure
Event: schedule
Branch: main
Commit: 5a595a6 Merge pull request #349 from AbdulWasih05/feat/asana-connector
Started: 2026-10-28T06:33:36Z
Finished: 2026-10-28T06:33:45Z

## Jobs
- bump: failure
  - failed step: Check the PR token is configured

## Failure log: bump
Errors:
- Set the COGNEE_BUMP_PR_TOKEN secret (see the header of this workflow).
- Process completed with exit code 1.

A few kilobytes of noisy log become a dozen lines an LLM can reason over. Each document also keeps the run's URL, so an answer can always be traced back to GitHub.

The demo: 15 real runs, three questions

I pointed the connector at the 15 latest completed runs of topoteretes/cognee-community on 28 October 2026. The LLM was an Azure OpenAI deployment, and embeddings came from text-embedding-3-large. Everything below is real output.

1. Fetch the runs. The connector pulled 15 runs, their jobs, and the logs of the failed jobs in 8.2 s. Only 3 had actually failed. 10 were waiting for approval.

2. Build the memory. One call, cognee.remember(), stored the 15 documents and built the knowledge graph and embeddings in 105.3 s.

await cognee.remember(
    github_actions_source(
        repos=["topoteretes/cognee-community"],
        max_runs_per_repo=15,
        include_failed_logs=True,
    ),
    dataset_name="github-actions-blog",
)

3. Ask questions. Here are cognee's answers, unedited:

Q: Which workflows failed recently, and why?

On 2026-10-28, three workflows failed:

Clay connector tests (#1): Python 3.11 and 3.12 both failed test_check_active_cancellation; extraction raised ResourceExtractionError: Sync cancelled by host.

Ruff Lint and Format (#1098): Clay code had a nested-if lint issue, unescaped regex patterns in tests, and a formatting issue.

Scheduled "Bump cognee in the database adapters" (#22): failed because the COGNEE_BUMP_PR_TOKEN secret was not configured.

The Klaviyo connector runs were marked action_required, not failed.

Q: How do I fix the failing bump workflow?

Add the COGNEE_BUMP_PR_TOKEN secret to the repository's GitHub Actions secrets (see the workflow header for details), then rerun the scheduled workflow. It failed because that required secret wasn't configured.

Q: Which workflows are waiting for approval?

The workflows marked action_required (waiting for approval) are:

Klaviyo connector tests

Vercel connector tests

Prometheus connector

Ruff Lint and Format (runs #1094, #1095, #1101, and #1102)

The first two answers are what I wanted. Each gives the cause and the fix, down to the failing test name and the missing secret, with no log open. The first even points out that the Klaviyo runs were waiting, not failing.

The third answer is close but not complete. It lists 7 of the 10 waiting runs and misses Ruff runs #1096, #1097 and #1100. Graph completion answers from the context it retrieves, so it isn't an exhaustive query. For an exact list, the table from step 1 is still the right tool.

How it can help your workflow

It helps most when you need the story across many runs, not the details of one.

Who	Question they can ask	What used to happen
Maintainer	"Which PRs are stuck waiting for workflow approval?"	Scan the Actions tab run by run
Contributor	"Why did the tests fail on my branch?"	Open the job, expand the step, scroll the raw log
On-call / release owner	"Is this the same error that broke `main` last week?"	Rely on memory, or search Slack
Team lead	"Summarize recent CI activity in this repo"	Build a dashboard, or just not know
AI coding agent	Reads the failure summary before proposing a fix	Fed a whole log, or nothing

Because it's a plain cognee dataset, CI history can sit next to your other data, such as docs, issues or code. One question can then draw on all of them.

Try it yourself

You need Python 3.11 to 3.13, a GitHub token, and an LLM key for cognee. For a public repo, a token with no extra scopes is enough. For a private repo it needs repo or actions:read.

git clone https://github.com/topoteretes/cognee-community
cd cognee-community/packages/connector/github-actions
uv sync
export GITHUB_TOKEN=$(gh auth token)
export LLM_API_KEY=...   # or put cognee's settings in a .env file

import asyncio
import cognee
from cognee_community_connector_github_actions import github_actions_source

async def main():
    source = github_actions_source(
        repos=["owner/repo"],
        max_runs_per_repo=50,
        include_failed_logs=True,
    )
    await cognee.remember(source, dataset_name="github-actions")
    print(await cognee.search(
        query_text="Which workflows failed recently, and why?",
        query_type=cognee.SearchType.GRAPH_COMPLETION,
        datasets=["github-actions"],
    ))

asyncio.run(main())

Useful options:

workflow and branch narrow the runs to one workflow file or one branch.
created_after limits how far back to go.
log_tail_lines controls how much of each failed step's output is kept (default 50).

Run it again later to sync. Runs that have dropped out of the window are removed from memory, so the dataset tracks your current CI.

If the PR is still open when you read this, use the branch from PR #383.

What I learned building it

The model needs the error, not the log. Raw Actions logs are mostly setup noise. Keeping only the ##[error] lines and the output just before them made the documents small and the answers sharper.
The network was the slow part. Fetching 20 runs took about 16 to 24 s, almost all of it waiting on the API. Fetching jobs in parallel helped. Asking GitHub for only the tail of a log did not, because the log storage ignores range requests.
Be polite to the API. The connector backs off and retries on rate limits and server errors instead of failing the whole sync.
Test without the network. The 31 tests replay fake GitHub responses, so they run in seconds and need no token.
Check the whole pipeline. I confirmed sync, cognify and search end to end, and that re-syncing a smaller window removes old runs.

If you try it, I'd like to hear what you ask your CI. Feedback and issues on the PR are welcome.

Links: cognee · cognee-community · PR #383

EcoSound: Using Open-Source AI to Get People Outside and Exploring Nature 🌿

Daniel Chege — Mon, 12 Oct 2026 02:24:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

What if we used AI to get people off their screens instead of keeping them glued to them?

That question inspired me to build EcoSound, an open-source, AI-powered application that turns ordinary outdoor experiences into opportunities to discover wildlife.

We're surrounded by nature, but how often do we actually stop to notice it? You might hear a bird singing outside your window, while walking through a park, or on your way to work, without knowing what it is.

EcoSound makes those small moments of curiosity more meaningful.

Instead of endlessly scrolling, users can step outside, listen to their surroundings, identify possible bird species, learn about wildlife, and take part in outdoor challenges.

Demo

https://ecosound-web.onrender.com/

Code

https://github.com/Daniel-1600/hactoberfest-week-1

How I Built It

I wanted open-source AI to be central to EcoSound, rather than simply adding an AI chatbot to an otherwise unrelated application.

To achieve that, I integrated two complementary AI models.

BirdNET 3.0 — Understanding wildlife sounds

BirdNET is an open-source acoustic machine learning system for bird identification.

Users record or upload audio. The Go backend processes the recording and forwards it to BirdNET for inference.

BirdNET returns candidate species, model scores, and the portions of the recording where calls were detected.

I deployed BirdNET on Modal using CPU inference, avoiding the need to run the model on users' devices.

Qwen3 1.7B — Turning discoveries into learning experiences

Identifying a bird is useful, but I wanted EcoSound to do more than return a species name.

I integrated Qwen3 1.7B, an open-weight language model, to provide educational explanations and outdoor activity recommendations.

Before generation, the backend retrieves curated species information, including habitat, diet, ecological role, conservation references, and ethical observation guidance.

That information is passed to Qwen so its response can be grounded in the available species record.

The backend validates the generated JSON and requires exactly three outdoor activities.

Qwen runs on a Modal GPU, independently of BirdNET.

Building the application

My technology stack:

Frontend :Next.js, React, TypeScript

Backend :Go

Database :SQLite

Bird identification : BirdNET 3.0

Nature explanations : Qwen3 1.7B

Model hosting : Modal

Web hosting : Render

Maps : MapLibre GL JS

Offline capabilities : PWA, IndexedDB, service worker

The Go backend connects the user-facing application to both AI services, manages stored discoveries, and handles validation and error responses.

Challenges I encountered

One of the biggest challenges was getting reliable inference from the cloud-hosted models.

Qwen initially returned authentication errors because the Modal proxy credentials were incorrect.

After resolving authentication, requests still failed during model cold starts. A direct request eventually returned HTTP 200 after approximately 185 seconds, including an HTTP 303 redirect.

I updated the Go client to handle Modal redirects safely and extended the request timeouts.

Another issue appeared when Qwen returned an explanation that failed the backend's JSON and content validation.

I refined the generation instructions, added controlled validation logging and retry handling, and expanded the tests.

Eventually, the complete pipeline returned HTTP 200, with the predicted species, curated wildlife information, an AI-generated explanation, and three outdoor activities.

This was an important lesson: deploying a model is only part of building an AI application. Handling cold starts, unreliable responses, validation, and model uncertainty is equally important.

Why Does Open Innovation Matter?

EcoSound would have been much harder to build as an independent project without accessible open-source AI.

First, open models give developers control.

I can inspect how BirdNET is integrated, build my own inference service, and choose where to run the model. With Qwen, I can control the prompts, generation settings, and validation behavior.

Second, open models make experimentation more accessible.

Instead of being tied entirely to proprietary AI APIs, I can deploy models on infrastructure I choose, compare inference options, and adapt the system as my requirements change.

Third, open innovation encourages reusable solutions.

EcoSound combines existing research and open technologies into a new experience focused on biodiversity discovery and outdoor exploration.

I didn't need to train a bird identification model or a language model from scratch. I could build on the work of open-source communities and focus on solving the user-facing problem.

That doesn't mean every component is free to run or that every model has identical licensing terms. EcoSound's application code is MIT-licensed, Qwen3 1.7B uses Apache 2.0, and BirdNET's model weights have separate noncommercial licensing restrictions.

For me, that's what makes open innovation exciting: it allows independent developers to turn existing research into useful experiences that might otherwise be out of reach.

And sometimes, the best use of AI isn't keeping us online.

It's helping us appreciate what's happening outside.

Prize Categories

Best Use of Render

I deployed the EcoSound web application using Render, making the project accessible through a public URL without requiring judges to install the application locally.

Render serves as the public entry point to an application powered by open-source AI models hosted independently on Modal.

Live application: https://ecosound-web.onrender.com/

EcoSound — Go Outside. Listen. Discover. 🌿

Instead of building another application designed to capture more screen time, I wanted to build something that makes the real world a little more interesting.