I'm building a flaky-test finder with Spring Boot, Go and SQS (v0.1.0)

Description and use

FlakeSince collects CI test results, stores them in PostgreSQL, and guarantees each run is recorded exactly once, enabling flaky‑test detection and historical analysis.

Problem

Flaky tests cause CI builds to fail intermittently, wasting time re‑running and investigating failures.

Outcome

FlakeSince reliably ingests CI test results, preserves full history, and ensures each run is stored exactly once, enabling future flaky‑test detection and analysis.

Workflow

• 1. GitHub Action uploads JUnit XML files to FlakeSince action.
• 2. Go ingest service validates API key, parses XML, and enqueues a message per CI run to SQS.
• 3. SQS (or ElasticMQ locally) holds the message until processed.
• 4. Spring Boot API reads the queue, checks for duplicates, saves the run to PostgreSQL, and deletes the message upon success.
• 5. If processing fails three times, the message moves to a dead‑letter queue.

Evidence

FlakeSince keeps the pass/fail history of every normal CI run, so it can also estimate since which commit a test became flaky, without re‑running anything.

Source

A small Go ingest service checks the API key, parses the XML and puts one message per CI run on a queue.

Source

If saving fails 3 times, the message goes to a dead‑letter queue instead of being lost.

Source