r/cicd

Keeping .env.example in sync with actual code usage is a manual chore that everyone forgets. I released envsniff to treat documentation-of-vars as a build requirement.

Why use it?

• Multi-language support: Scans JS, Go, Python, and even Shell scripts.
• Zero Config: The default setup finds most standard usage patterns.
• Auto-remediation: You can set commit: true to let the Action maintain the example file for you.

​

- uses: harish124/envsniff@v0.1.0
  with:
    fail-on-drift: true
    commit: true

Check it out here: https://github.com/harish124/envsniff

Pls drop a star on Github

Disclosure up front: I'm a co-founder at Mendral (YC W26). We build an agent that debugs CI failures. Not a pitch, sharing what we learned. Mods can take it down if it doesn't fit.

We run around 1.5B CI log lines and 700K jobs per week through ClickHouse for our agent to query. It writes its own SQL, no predefined tool API. The LLM-on-logs angle is covered to death. The CI-specific parts are what I haven't seen discussed much.

1) GitHub's rate limit is the thing that kills you.

15K requests per hour per App installation. Sounds generous until you're continuously polling workflow runs, jobs, steps, and logs across dozens of active repos, while the agent itself also needs to hit the API to pull PR diffs, post comments, and open PRs. A single big commit can spawn hundreds of parallel jobs, each producing logs you need to fetch.

Early on we'd burst, hit the ceiling, fall 30+ minutes behind, and the agent would be reasoning about stale data. Useless if an engineer is staring at a red build right now.

Fix was boring. Cap ingestion at ~3 req/s steady and use durable execution (we're on Inngest) so when we hit the limit we read X-RateLimit-Reset, add 10% jitter, and suspend the workflow with full state checkpointed. When the window resets, execution picks up at the exact API call it left off on, so there's no retry logic, no dedup, no idempotency work. The rate limit becomes a pause button. P95 ingestion delay is under 5 minutes, usually seconds.

2) Raw SQL beat a constrained tool API by a wide margin.

We started with the usual get_failure_rate(workflow, days), get_logs(job_id), etc. It capped the agent at questions we'd thought of. Switching to raw SQL against a documented schema unlocked investigations we never scripted. Recent models write good ClickHouse SQL because there's a huge amount of it in training data. Median investigation across 52K queries is 4 queries, 335K rows scanned, ~110ms per raw-log query.

3) Denormalize everything. Columnar storage eats the repetition.

Every log line in our table carries 48 columns of run-level metadata: commit SHA, author, branch, PR title, workflow name, job name, runner info, timestamps. In a row store this is insane. In ClickHouse with ZSTD, commit_message compresses 301:1 because every log line in a run shares the same value. The whole table lands at ~21 bytes per log line on disk including all 48 columns. The real win isn't the disk savings, it's that the agent can filter by any column without a join. When it asks "show me failures on this runner label, in the last 14 days, where the PR author is X," there's no join to plan around.

What I'm curious to hear from this sub:

- Anyone running an ingestion layer against GitHub Actions (or Buildkite, CircleCI) that has to share API budget with other consumers? How are you splitting it? We ended up keeping ~4K req/hour headroom for the agent and tuning ingestion under 3 req/s. Trial and error.

- Anyone using columnar stores (ClickHouse, DuckDB, Druid) for CI observability specifically, vs general log platforms (Loki, Elastic)? Tradeoffs?

Longer writeup with the query latency histogram and the rate limit graphs is here if you want detail: https://www.mendral.com/blog/llms-are-good-at-sql

Hey folks,

I've been building QAPIR (https://app.qapir.io), a tool that generates API test scenarios automatically from API docs or an OpenAPI spec.

The idea is to reduce the amount of test code and setup usually needed for backend testing. You paste a link to API docs (or upload an OpenAPI spec), and in a couple of minutes it generates a working baseline test suite with validations, environment variables/secrets, and chained calls.

Tests can be edited in a simple YAML format or through a UI editor.

Right now it's focused on REST APIs, but I'm planning to add things like:

• CI integrations (GitHub / GitLab)
• more protocols (GraphQL, WebSockets, gRPC)
• additional test steps (DB/cache queries, event queues, webhook testing, HTTP mocks)

It's very early, and I'm looking for a few SDETs, Developers and QA engineers willing to try it for free and give honest feedback.

If you're doing API testing and are curious to try it on a real service, I'd really appreciate your thoughts.

Link:
https://app.qapir.io

Thanks!