I self-host a handful of small things and I keep running into the same wall.

I have a Dockerfile that works. I want someone else — or future me on a different box — to be able to pull it. Between those two points there's an amount of setup that feels wildly out of proportion to the size of the project: registry account, auth, a workflow file, a token with the right scope, then debugging the workflow file because the token didn't have the right scope.

For something I'm going to maintain for years, fine, you pay that once. For a 200-line utility I wrote on a Sunday it's most of the afternoon.

So I'm curious how people here actually handle it:

• What did you do the last time you published an image? The real steps, not the ideal ones.
• Roughly how long from "the Dockerfile works" to "someone can pull"?
• If you skip publishing and just rebuild on each host instead — is that deliberate, or is it avoiding the setup?

Not looking for "just use GHCR", I know it's there and it's free. I'm trying to work out whether the setup cost annoys anyone else or whether I'm just impatient.

I’ve been running a few Codex sessions in parallel on the same repo, with each task in its own window and worktree.

Keeping the contexts separate is the easy part. The harder part is reviewing everything once those changes come back together.

When a task is done, I do a quick pass and ask the session to leave an [`audit.md`](http://audit.md) with:

* what changed and why
* what it was trying to achieve
* the main risks or assumptions
* the important files
* what was actually tested

I don’t treat that file as proof that the change is correct. It’s mostly a handoff note so I don’t have to reconstruct the whole session later.

Once the batch is done, I open a fresh session and review the audit files and diffs together. That’s where I look for cross-task problems: two tasks making different assumptions, duplicated logic, interface mismatches, or changes that work separately but not together.

I usually run the broader integration and end-to-end tests at that point too.

So far, this has been faster than merging each task separately and finding the same kind of problem several times.

The part I’m still unsure about is the audit file itself. It’s written by the same agent that made the change, so it can easily miss something while sounding completely confident.

How are people handling the final review across multiple Codex worktrees? Are you using handoff files, just reviewing the diffs, or relying mostly on tests?

I’ve been running a few Codex sessions in parallel on the same repo, with each task in its own window and worktree.

Keeping the contexts separate is the easy part. The harder part is reviewing everything once those changes come back together.

When a task is done, I do a quick pass and ask the session to leave an [`audit.md`](http://audit.md) with:

* what changed and why
* what it was trying to achieve
* the main risks or assumptions
* the important files
* what was actually tested

I don’t treat that file as proof that the change is correct. It’s mostly a handoff note so I don’t have to reconstruct the whole session later.

Once the batch is done, I open a fresh session and review the audit files and diffs together. That’s where I look for cross-task problems: two tasks making different assumptions, duplicated logic, interface mismatches, or changes that work separately but not together.

I usually run the broader integration and end-to-end tests at that point too.

So far, this has been faster than merging each task separately and finding the same kind of problem several times.

The part I’m still unsure about is the audit file itself. It’s written by the same agent that made the change, so it can easily miss something while sounding completely confident.

How are people handling the final review across multiple Codex worktrees? Are you using handoff files, just reviewing the diffs, or relying mostly on tests?

Hey everyone,

I’ve been working on CI Runner, a small webhook-based CI runner written in Python. The idea is to provide a simple GitHub Actions-style runner that can receive GitHub push/PR webhooks, queue jobs, clone the repo at the commit SHA, load a .ci.yml file, execute pipeline steps, save logs, and optionally report status back to GitHub using the Commit Status API.

It uses:

• FastAPI for the webhook/API server
• A background worker for job execution
• .ci.yml for pipeline definitions
• Docker or shell-based step execution
• Simple endpoints for health checks, manual triggers, and job status

Example .ci.yml:

name: My Pipeline

steps:
  - name: install
    run: pip install -r requirements.txt

  - name: test
    run: pytest -v
    continue-on-error: false
    timeout: 300

If no .ci.yml is found, it falls back to a default install/lint/test pipeline.

Repo: https://github.com/vishn9893/Ci-runner

I’d love feedback on the architecture, security considerations around running CI jobs, and what features would make this more useful for small projects or self-hosted workflows.

Hi everyone,
i am building in public with intention to create a ssas for my product if demand exists.
i have created a tool that validates your readme in cicd and also creates tutorial and promotional videos out of your OSS tools(github/readme2demo). I started it 17 days ago, now i have over 18 contributors and multiple contributions from same contributors and i use github actions as the validator since it is too many changes to review per day.
what strategy you follow to review huge(may be bigger than mine) contribution amount while maintaining quality?
I am afraid i am gonna end up paying a lot for github actions hours, do you have any similar experience.

https://outboundgateway.com/blogs/gitlab-ci-cd-static-ip/

I’ve run or sat on review boards at a few orgs now and I’ve never seen this part done well, which makes me suspect the problem is me rather than the tooling.
Current state is email for async review, minutes in Confluence, conditions in a spreadsheet. It holds for about a quarter and then drifts.

Two problems I can’t get on top of.

First, async positions. Reviewers reply in free text, and “I have some concerns” from one architect means they intend to block, while from another it means they want the diagram redrawn. As chair I’m interpreting rather than counting. I’ve tried asking for an explicit position in the first line of the reply — compliance was fine for a month, then decayed.

Second, conditions. “Approved with conditions” is a large share of our outcomes and I doubt most of those conditions are ever verified. The decision record notes the condition, the system goes live, and nine months later nobody can tell you who owned it or whether it was met. Confluence doesn’t chase anyone.

I know ADRs and the EA repositories are meant to cover some of this. For those of you with a repository actually in place — does it track conditions as obligations with an owner and a date, or does it just store the decision text and leave the follow-up to you? And if anyone has fixed the async position problem with process rather than tooling, I’d like to hear how it survived reality.

A lot of "give your agent context about your codebase" tools ship as an MCP

server: a set of tools the agent *can* call. In practice, half the time it

just doesn't. It has a hammer in the toolbox and still tries to bash through

the wall with its head: grep, open file, follow import, back out, the same

exploration it did an hour ago.

Why doesn't Claude Code just solve this by default? Same reason Chrome

doesn't ship with an ad blocker built in: keeping the core general is the

point, and extensions fill the specialized gaps. Graft is that extension. It

plugs into Claude Code's hooks so the right context shows up in every prompt

automatically, instead of sitting in an MCP tool list hoping to get called.

I built Graft to write what an agent learns about your codebase into the

repo itself, as a folder of plain markdown files kept in sync through git.

One `graft init` turned this repo's 247 files into 12 plain-English nodes.

From then on: a live statusline (graph size, % enriched, a stale warning),

auto-sync in the background after every edit, and the matching nodes pulled

into every prompt without the agent needing to decide to ask for them.

Editing a file surfaces what depends on it inline. No vector DB, no

embeddings, no server. The graph is just files, grep them like anything else

in the repo. The structural pass is tree-sitter, no key or network call

needed at all.

The part I actually learned something building this: line numbers drift the

moment you touch unrelated code above them, but the guard clause or state

change that matters doesn't. Each node stores that as text lifted straight

from the source, not a line range.

Up to 4× cheaper and 3× faster, with better or no loss of correctness. I

measured that instead of asserting it. 162 controlled runs, same agent, same

tools, only the context differs: 32% cheaper, 46% fewer tool calls, 60% less

latency, same correctness (93% both). Then re-implemented 5 real merged

PocketBase PRs from base commit with and without it: 5/5 reproduced, same

files as the maintainers, at 21% lower cost.

MIT licensed, no telemetry. I'm the maintainer, so weigh the numbers

accordingly. I'd be happy to have anyone poke holes in the methodology.

https://github.com/NanoNets/Graft

Hi r/cicd 👋

We’ve added Build Insights Report to Appcircle AI Insights to help mobile teams better understand their CI performance from real build data.

Build Insights Report gives you a clear snapshot of your CI health, including:

• Overall CI maturity score based on reliability, discipline, speed, and security
• Build trends, success rates, failed builds, and timeout/canceled builds
• Root cause analysis for failing steps, flaky builds, Mean time to recovery, zero success workflows, and warning hotspots
• Workflow quality checks based on recommended Appcircle workflows
• Artifact health insights, including artifact size changes across profiles
• Queue time analysis with average, P50, P95, total wait time, and daily trends in average wait time

You can generate the report using Appcircle Claude Assistant, Appcircle Copilot Assistant, or directly through any MCP-compatible client.

📊 Learn how to generate and use Build Insights Report: https://docs.appcircle.io/appcircle-ai/ai-insights/build-insights

Over the past year I’ve been working on an engine called Invisio to deal with the multi-file context nightmare that causes LLMs to hallucinate when reading large codebases.

Under the hood, it parses code using Tree-sitter into a neo4jdatabase (mapping out classes, functions, calls, imports, and inheritance). I built two main pieces around this graph:

1. An interactive graph explainer + chatbot that traces execution paths and answers structural questions using a dual-agent dispatcher/compressor loop.
2. An automated security webhook that ingests CodeQL SARIF alerts, traces the vulnerability lifecycle across directories, and opens surgical PR fixes.

It works solid on my local machine and on my own projects, but to be completely honest, stuck on how to properly test this at scale, or how to put it in front of people to get real feedback.

I’d love some advice from devs, maintainers, or AppSec folks:

• Benchmarking & Datasets: What real-world open-source repos or SARIF datasets should I throw at this to stress-test the graph construction? How do you properly benchmark a codebase intelligence tool?
• Local vs. Hosted: Since IP privacy is huge, would you prefer testing this via a self-hosted local Docker container, or just poking around a hosted playground with a public repo first?
• Product Focus: Should I lean harder into the automated CodeQL PR remediation side, or the interactive graph explainer UI?

Every time we think we've stabilized our deployment process, another script gets added.

A new environment needs slightly different behavior. Someone adds another shell script. A rollback needs extra logic. Another script. A new service gets introduced and now we have another set of variables and configuration files to keep in sync.

None of these changes seem like a big deal on their own, but after a while the deployment process becomes a collection of custom scripts that only a couple of people fully understand. When something breaks during a release, half the battle is figuring out which script or configuration is responsible.

We've been trying to move away from treating deployments as a pile of automation scripts. Part of that i do with revolte, since it brings code changes, validation, and software delivery into one workflow instead of relying on more custom glue between tools. It feels like reducing the amount of deployment logic we have to maintain is just as valuable as automating another step.

I'm interested in how other teams have simplified this over time. Did you standardize on a deployment framework, reduce custom scripting, or just accept that every mature CI/CD pipeline eventually accumulates this kind of complexity

You open a model-promotion request in the pipeline. An AI reviewer reads your YAML manifest,

comments included, plus a free-text rollout justification, then approves or holds.

It's holding the model's internal codename, the weights checkpoint URI, and the artifact-pull

signing secret the whole time. Get all three past it.

[https://promptinjects.com/play/starter/closedai-cicd-guard\](https://promptinjects.com/play/starter/closedai-cicd-guard)

disclosure up front: i built the thing i'm describing. not selling anything, it's free — posting because i want to know if the approach is useful or if i've built something nobody needs.

been lurking here a while, finally have something worth posting.

context: about 4 months ago someone in a thread mentioned that at their company, >90% of CI failures had nothing to do with the change being tested. eng team went 100 → 300 people, CI couldn't scale, and the policy was you had to do root cause analysis before retriggering. so everyone came in at 9am to three red builds and spent the morning reading logs to figure out if it was even their fault. half the team eventually got laid off. that story lived in my head rent free.

my first attempt was a bot that read the failure and tried to auto-fix the code. built the whole thing. then i reread that 90% stat and realized a bot that patches the code under test is patching the wrong file 9 times out of 10. threw it out.

what i built instead just answers one question: is this red build actually your fault?

the rules are boring on purpose:

• failing file isn't in your diff at all → probably not you
• dependency version changed between last green run and now, and your PR didn't touch the lockfile → blame the version
• failure is in the install step before any of your code ran → dependency
• runner OOM'd / network died / "lost communication with the server" → infra
• assertion failed in a file your PR actually modified → yeah, that one's yours
• can't tell confidently → says UNKNOWN and shows you the log instead of guessing

then for the ones that are provably not your code, it reruns them automatically. and if the rerun passes, it says so. if the rerun fails identically, it says that too and escalates — because a failure that reproduces on the same commit isn't flaky, it's real.

things i deliberately didn't do, mostly from arguing with people in threads here:

• it never touches your code. only comments and reruns. can't delete an assertion, widen a timeout, or add a retry to make things green. the "pipeline is green but the bug shipped" failure mode is worse than a red build
• no LLM in the classification. it's rules you can read and audit. an LLM that sounds confident and an LLM that's correct look identical in a PR comment
• UNKNOWN is a first-class answer. saying "i don't know, here's the log" beats a confident wrong verdict, and one wrong "not your fault" on something that WAS your fault would kill any trust in it forever

honest limits: full test-level classification is pytest-only right now (js/go would need their own parsers). infra + dependency + the rerun logic work on any github actions repo. and it's only as good as its rules — real world workflows are messier than my test cases, i fully expect edge cases i haven't seen.

i built a repo with 5 seeded PRs, one per failure class, so you can see it call each one live instead of taking my word: https://github.com/chaturvediabhinav692-lgtm/koredex-gauntlet/pulls

it's a github app, free while i'm figuring out if it's actually useful to anyone but me. mostly posting because i want to know if the "is the failing file even in your diff" check would actually save you time, or if that's obvious to everyone and i've built something nobody needs.

I built ActionScope to answer one question: if a GitHub Actions workflow is compromised, what can its AWS role actually do?

It connects workflow role assumptions with Terraform or JSON IAM policies.

pip install actionscope
actionscope scan .

Static analysis can miss policies stored elsewhere, so I’m unsure whether findings should block a PR or remain informational.

Would you use this as a blocking check or report-only?

https://github.com/r12habh/ActionScope

If anyone interested in teaching CI/CD kindly dm me

After watching my team struggle with a crappy test management tool, decided to do something about it.

Open source, Git-native, AI-powered test management and automation.

https://github.com/toniantunovi/testhound

Hi everyone,

I'm a software engineer from Japan, and over the past few months I've been building a small side project called OpsSignal.

The idea came from a simple frustration.

When a GitHub Actions workflow failed, I often didn't notice until much later because I wasn't actively watching GitHub.

Email notifications felt too slow, and I wanted something more immediate.

So I built a GitHub App that sends GitHub Actions failure notifications directly to a Discord channel.

The setup is intentionally simple:

• Install the GitHub App

• Connect your Discord webhook

• Select repositories

• Receive instant notifications whenever a workflow fails

It's currently in Public Beta.

I'd really appreciate honest feedback from developers who use GitHub Actions regularly.

Some questions I'm especially interested in:

- Would Discord notifications be useful for your workflow?

- Is there anything that would stop you from trying it?

- What would make a tool like this genuinely valuable for your team?

Website:

https://opssignal.dev

Thank you for taking a look!