r/cicd

It won't be surprising if GitHub tightens rate limits at some point. They already limit heavily, but the volume coding agents are pushing now is a different shape and it's only going up.

The pushes themselves are cheap. What costs them is every push firing off Actions runs and webhooks behind it. Their availability reputation is already taking a beating from all the outages.

When a CI pipeline fails and multiple causes are possible, what evidence do you check first, and how do you choose between rerunning, reading more logs, comparing the last successful build, or investigating the recent diff, or checking the version compatibility with infra.

We are redesigning our CI/CD pipelines and trying to figure out the cleanest way to structure deployments.

Which route do you guys prefer?

1. One unified job: A single parameterized job where you just pass in the environment variable (develop,staging, prod, etc.).
2. Split jobs (same file): Explicitly separate jobs likE edeploy-develop ,deploy-staging and deploy-prod sitting in the same workflow.
3. Hard split: Completely separate files for lower envs(develop and stage) vs. production.

I want to avoid copy-pasting YAML, but I also don't want a massive, over-engineered "smart" job that's hard to debug. What's the sweet spot?

What strategy are you following in your org?

Currently we keep our DevOps-related files (Dockerfile, values.yaml, etc.) on the Jenkins server instead of in the repo. During pipeline runs, we copy these files in at runtime.

I'm considering moving these files directly into the repository instead. The problem: if a developer accidentally edits the Dockerfile or values.yaml, it could cause issues.

So I want a way to either:

1. Prevent developers from editing those specific files, or
2. Require PR approval specifically for changes to those files

What's the best approach for this?

The whole appeal of Replit, Lovable and Bolt is skipping the SDLC entirely, prompt to live URL in minutes, with no pull request for security to hook a check into, and honestly that's the pitch working exactly as intended, it's just not intended for us. The core problem isn't the app we know is being built on one of these platforms, because at least there you can have a conversation about it, it's the one nobody mentions, built by someone in another department who never looped security in and has no reason to think they should have, since as far as they're concerned they just made a form or a dashboard, not "shipped infrastructure."

We've tried a few things on our end, adding it to onboarding, sending reminders in engineering channels, none of it really moves the needle because the people building these apps aren't reading security's Slack channels in the first place. How is everyone else gating something that structurally bypasses the pipeline, especially when the org chart means the builder and the reviewer will never naturally cross paths?

Been working on a small side project for the last few months called reqsh.

The idea started because I was constantly jumping between curl commands, Postman, editing headers, copying tokens, changing base URLs... it just felt more annoying than it should.

So I ended up building a terminal-first HTTP REPL where you stay in one interactive session. You can save base URLs, keep headers around, use variables, organize requests and just experiment without rewriting the same command over and over.

It's written in Rust and still pretty early, but people have started opening PRs which has been really cool to see.

Not trying to replace every API client out there. I just wanted something that fits the terminal workflow better.

I'd genuinely love some feedback from people who spend a lot of time working with APIs. What's missing? What feels awkward? Or is there something you wish tools like this did better?

GitHub: https://github.com/hars-21/reqsh
Website: https://www.reqsh.dev/

Am I the only one who finds GitHub actions a small black hole when you're looking to optimise?

There is really limited analysis or data available, I had to build my own UI and system just to get the details I wanted. Example, outliers for job run times, AVG step run time, flakey runs.

Am I missing something, does everyone fly blind or are they using a third party view?

Everyone’s .claude/skills/ folder is filling up with stuff pulled from marketplaces, gists, npx skills, random repos. On a team, those files land in the repo and nobody reviews them the way they’d review a dependency bump. A skill is just instructions your agent will follow and it changes silently.

So I wrote agpm (Apache-2.0). It does one thing:

1.	agpm sync writes two files: harness.json (what’s approved to exist) and harness.lock (a sha256 per file)

2.	The PR that changes harness.json is the approval. A human reviews the diff.

3.	agpm check in CI fails if anything on disk drifted from what was approved

It watches .claude/skills/, .agents/skills/, .claude/agents/*.md, and .claude/commands/*.md. It installs from a registry too, but installing is explicitly not approving : the PR is.

npx @baselane/agpm init

Repo: httpss://github.com/baselane-sh/agpm

Mostly curious whether other people are hitting this yet, or whether skill sprawl is still small enough that nobody cares. If you’ve got a different approach I’d like to hear it.

We've become pretty comfortable putting conventional applications through CI:

• dependency scanning
• SAST
• CodeQL
• secret scanning
• container scanning
• IaC checks
• security policies ...

But what happens when the application being deployed is an AI agent? That may not look particularly interesting in a conventional code diff. But from a security perspective, it could be a significant change.

I'm experimenting with a different CI question:

“What capabilities changed in this PR?”

--

We've implemented an early version of this approach in an open-source static analyzer and connected it to GitHub Actions. (ikaruscareer/SafeAI at GitHub)

The scanner runs locally against the repository and doesn't execute the agent or send the source to a remote service.

I'm curious how other teams approach this.

[removed]

How are you guys using Claude code or any other ai tool for devops. My team have started using Claude code but we are struggling to make it work at team level. If I create tasks which have well defined acceptance criteria, team mates are still producing code using Claude code which doesn't meet AC. If I review merge request by Claude code and then run experts opinions on it, it finds additional issues. I then ask codex to review same MR and then codex finds additional issues. When I merge both codex and Claude feedback and ask Claude to fix the issues and ask Claude to run experts reviews, it finds issues again. Codex review find issues. It is never never ending. What are you guys doing to fix it ? My code is infrastructure as a code terraform deploy on AWS. We are using eks , aurora DB, gitops, argocd, cloud front, API gateway S3 etc

I'm using GitHub Environments (INT, STAGE, PROD), each with its own AWS_ACCOUNT_ID. Works great when a job targets one environment - assume the right role, deploy to that account.

The central ECR registry is in INT env. STAGE/PROD ECS tasks need to pull from that registry, so at CDK synth time we need:

1. INT’s account ID (where the images live)
2. INT + STAGE + PROD account IDs (ECR repo policy principals)

The snag: Environment variables are only available to the jobs that declare that Environment. A job with environment: STAGE can see STAGE’s AWS_ACCOUNT_ID, but not INT’s. So I can’t just write ${{ vars.AWS_ACCOUNT_ID }} for “the INT account” while deploying STAGE.

I’d rather not invent a parallel config surface if Environments already hold the source of truth.

How is everyone else solving “job in env X needs a non-secret config value from env Y” - especially for central registry / multi-account AWS setups?

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?

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?