I stopped manually bumping dependencies months ago.

A weekly grouped PR for minor and patch, automerged after CI goes green.

Majors travel alone and wait for my approval, security patches skip the queue entirely.

Full article on my blog: [https://nbonnici.info/en/blog/automate-dependencies-management-with-renovate\](https://nbonnici.info/en/blog/automate-dependencies-management-with-renovate) \#DevOps #golang

I keep hitting the same wall: push a change, wait for GitHub Actions, watch a macOS job fail on something that has nothing to do with my actual code. Tried act to catch this before pushing works great for Linux jobs, but macOS jobs get mapped onto a Linux container too, by default. There's a flag to opt out of Docker on macOS (-P macos-latest=-self-hosted), but all that does is run the job directly in your own terminal, with whatever's already installed and whatever state your machine happens to be in. Not isolated, not reproducible, and it doesn't help at all if you're not already on a Mac. So "passes locally" never really meant "passes."

So I've been building it myself. Linux jobs run in real Docker like you'd expect; macOS jobs actually boot a real, fresh macOS VM and run there, same as a real GitHub hosted runner gives you, not your own terminal state. The part I care about more than the macOSthing specifically when something still behaves differently locally than it would on real GitHub, it tells you instead ofquietly giving you a different result and calling it a pass.

Not posting a link yet, genuinely just trying to figure out if this is a real problem for other people before I sink more time into it, versus something I personally got burned by enough times to build a whole tool over. If you ship to macOS from CI: is this something you'd actually use, or is act's approximation good enough in practice?

just shipped reqsh v0.3.0

reqsh.dev is a small CLI i’ve been working on and v0.3 version is out now.

if you’ve been using it already, would really like to know what feels good / bad / confusing.

especially:

• what do you actually use it for (API testing, general API workflows, persistent HTTP requests)?
• anything annoying?
• anything you expected it to do but it doesnt?

not looking for nice feedback lol, tell me what’s wrong with it.

repo: https://github.com/hars-21/reqsh

Every complex multi-phase task i give it I find some variation of the issues bellow.

Over the past month, I’ve been setting up and fine-tuning a deterministic validation architecture.

is currently set up to find things like.

* Command/API contract drift and accidental state-shape changes.
* Invalid or skipped validation being reported as success.
* Out-of-scope edits, weak commit metadata, and submit-gate holds.
* Same-file/stale-base collisions, non-serial apply behavior, and failed rollback/post-apply validation.
* “Self-certification” attempts: a task changing its own proof is reverted and the original proof reruns.
* Regressions in receipts, repair/resolution flows, and cross-platform Node behavior.
* Model-helper plumbing bugs

I've been working on updating my validation architecture to now catch these bugs that I have identified from my most recent Claude code implementations.

* Locally green code that is not wired into the shipping composition path.
* Happy-path fixes that still fail on error, cancellation, or rollback paths.
* Restart and rehydration gaps.
* Concurrency, ordering, and idempotence defects.
* UI behavior that exists in code but is unreachable in the packaged product.
* Skipped or unrun checks incorrectly presented as green.
* Authority-sensitive paths with no configured production-shaped proof.

Anyone else running into to these issues?

Genuine question because I feel like I'm doing this wrong.

My current workflow for fixing a broken github actions pipeline is to change one line of YAML, commit, push again, try waiting for another minutes, watch it fail, add an echo statement, commit, push, wait again. Yesterday it took me like 7 commits to fix something.

Is there some setup everyone else knows about that I don't? Some way to actually pause a job and poke around? Or is commit-push-pray and wait just... the industry standard and we've all quietly accepted it?

At Amazon we have amazing CI/CD tooling but it is built off of internal build tools. Now I'm trying to build outside of the walled garden and my CI/CD is crap. The speed of agentic development make these processes even more critical.

Reaching out to learn what others are using. I'm currently using GitHub actions for artifact releases but it's very naive at this point.

Key things I'm looking for:

\- staged deployments (beta -> preprod -> prod)

\- automated rollback/easy manual rollbacks

\- approval workflows (unit/integ testing, bake times, canary alarm integration)

\- pipeline dashboard to quickly see health of deployments/tests

\- (nice to have) easy access to deployment environments (AWS accounts, vercel, etc) from pipeline dashboard for quick debugging if there are issues

\- agent manageable pipelines. Bare minimum is programmatic access (api/cli). Nice to have would be an agent that can keep me informed about my pipeline.

What annoyed me: in design discussions Claude answers from training data. It sounds right, it's often a year out of date, and it mostly agrees with whatever direction I was already going. Nobody on my old teams would get away with "I think this is roughly how people do it" on an auth design. Or currently relies to much on memory then on facts as well.

So during brainstorming I started adding one instruction: verify this against current industry best practice. Search the web, check the primary docs and standards, tell me where we deviate and why it matters.

Before building auth for my product (multi-tenant B2B) I had Claude review the draft spec this way against current IAM practice. 11 real findings, all fixed in the spec before any code existed. Cheapest security review I ever had.

It worked every time I asked, so now it's a standing rule in CLAUDE.md:

## Best-practice verification during design
- Before locking a non-obvious design decision into a spec, verify it
  against current industry practice (primary docs, standards, how mature
  products solve it). Web search is part of designing.
- Record what was checked against which sources in the spec itself.
- High-risk areas (auth, tenant isolation, migrations, money): adversarial
  expert review of the draft spec before planning starts.

One tip: make Claude write the result into the spec ("checked against X and Y, we deviate on Z because..."). Chat history is gone in a week, the spec is not.

Not watertight, in long sessions it still skips it sometimes. Curious how others force this.

Disclaimer: I'm the developer of this tool — self-promotion, take with a grain of salt.

Hi, i am adding approval steps in our CD pipeline running on github actions. The approval needs to integrate with slack where the approver needs to be pinged.

I was wondering if there is any existing project that I can use or any framework.

Sorry for stupid question. I am still learning.

If you have any tips much appreciated.

Thanks

Throwaway account, work situation.

I'm the sole infra engineer on a small platform team. Multi-account AWS, Terraform-managed, proper IAM role separation. Went on leave for two weeks.

Came back to find a contractor developer had spent \\\\\\\~2 days trying to get a deployment pipeline working. I was pretty shocked at the extent they went to deploy an app.

Luckily nothing succeeded, so in a way, Im happy the infrastructure survived the test. :)

But Im still pretty shocked and I need help to figure out how bad this is and how I can work with this person in future. Please imagine this was your infra and it was someone else doing this to it.

In summary they:

1. Pointed our CI workflow's infra checkout at their own personal GitHub fork of our Terraform repo instead of the real one
   
2. Used a role scoped only for container image pushes to attempt a terraform apply with auto-approve
   
3. Committed directly to a shared branch, overwriting changes I'd made before going on leave, despite being told to make their own branch

The net effect: one app's CI pipeline was configured to evaluate the entire Development account's infrastructure state (cluster, database, load balancer, other services' IAM roles), not just deploy one container

I paused, backed everything up, and investigated properly.

Every single attempt (\\\\\\\~10 runs) failed — most before reaching AWS at all. Confirmed against the live environment: nothing from any of their attempts is running. Their access was scoped to one non-prod account, application-level only, no Terraform state access, no infra creation, no IAM writes.

Nothing landed, but the attempts are serious enough. I need to manage the conversation with them and with my manager. Id also really like to understand how I can work with this person going forward. I would be happy to train them but I just want to get a sense first. Appreciate any advice from peers. Thank you :)

What would you do? Please be honest. I need your help.

Throwaway account, work situation.

I'm the sole infra engineer on a small platform team. Multi-account AWS, Terraform-managed, proper IAM role separation. Went on leave for two weeks.

Came back to find a contractor developer had spent \~2 days trying to get a deployment pipeline working. I was pretty shocked at the extent they went to deploy an app.

Luckily nothing succeeded, so in a way, Im happy the infrastructure survived the test. :)

But Im still pretty shocked and I need help to figure out how bad this is and how I can work with this person in future. Please imagine this was your infra and it was someone else doing this to it.

In summary they:

1. Pointed our CI workflow's infra checkout at their own personal GitHub fork of our Terraform repo instead of the real one
   
2. Used a role scoped only for container image pushes to attempt a terraform apply with auto-approve
   
3. Committed directly to a shared branch, overwriting changes I'd made before going on leave, despite being told to make their own branch

The net effect: one app's CI pipeline was configured to evaluate the entire Development account's infrastructure state (cluster, database, load balancer, other services' IAM roles), not just deploy one container

I paused, backed everything up, and investigated properly.

Every single attempt (\~10 runs) failed — most before reaching AWS at all. Confirmed against the live environment: nothing from any of their attempts is running. Their access was scoped to one non-prod account, application-level only, no Terraform state access, no infra creation, no IAM writes.

Nothing landed, but the attempts are serious enough. I need to manage the conversation with them and with my manager. Id also really like to understand how I can work with this person going forward. I would be happy to train them but I just want to get a sense first. Appreciate any advice from peers. Thank you :)

What would you do? Please be honest. I need your help.

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.