Ivan Baha’s Post

I spent a few weeks telling Claude Code to handle CI failures itself. Run gh pr checks, parse the JSON, find the error, fix the code. It worked. In short sessions. The longer the session ran, the worse it got. The GitHub API returns verbose JSON. A single check run log can be tens of thousands of lines. The agent ingests all of that to find the three lines that actually matter. In a fresh context window, it manages. Three hours into a loaded development session? It starts hallucinating fixes for the wrong error or missing the signal entirely. I noticed a pattern. Each failed CI parsing attempt added more noise to the context, making the next attempt less likely to succeed. The agent wasn't getting dumber. Its context was getting noisier. So I built bellwether. It's a TypeScript CLI that reads your PR state, CI status, review comments, merge state, and returns compact filtered output. The actual compiler error, not the ten thousand lines around it. I'm not sure this is the final shape. But raw GitHub API output vs filtered signal, that's the difference between an agent that degrades over a session and one that stays sharp. #devtools #opensource #aiengineering

Want to migrate Container Images between registries Without Docker or Privileged Access? Use Skopeo Why not just retag with the Docker client? 🤔 * Using the Docker client means exposing the Unix socket of the Docker Daemon * And that effectively grants root-level control over the host In secure setups, this is often unacceptable ❌ The key realization is: Pushing and pulling container images is just an HTTP operation (OCI registry API); no namespaces, no cgroups, no daemon required. 👉 So, moving container images doesn’t actually require a container runtime. 💡 Skopeo can also be run safely within containers, no need for docker-in-docker, no need to mount the unix socket either. Project's link on Github 👇 https://lnkd.in/dSx2UiMk #devops #skopeo #docker

Wild leak: Claude Code’s source code is reportedly out. A sourcemap shipped in Anthropic’s public npm package appears to have exposed the full TypeScript codebase, and researchers say the leaked code matches the published package byte-for-byte. This is a reminder that source maps are not harmless build artifacts. In the wrong place, they can reveal far more than stack traces: internal structure, implementation details, and security assumptions. For teams shipping JS/TS: • strip sourcemaps from public builds • audit what npm publishes • verify CI/CD output before release • treat bundle settings like security controls A small build-time mistake can become a full code disclosure. #AppSec #SupplyChainSecurity #DevSecOps #InfoSec

What makes DeployStack interesting is not just what it does, but how it works - GitHub Webhooks trigger deployments - Jobs flow through Apache Kafka for async processing - A consumer builds containers without blocking the server - Real-time logs stream via WebSockets - Fully containerized with Docker Building this pushed me to truly understand - Event-driven architecture - Async systems at scale - CI/CD internals - Secure self-hosting Still evolving and many things more to build on this For more details, check out: https://lnkd.in/gmzAk2TD Repo link: https://lnkd.in/g5B4Rnz5 I've also written a blog explaining the whole project, would love to know your thoughts on that too. Blog: https://lnkd.in/gsXTKT4H I would love to have contributions on DeployStack #SystemDesign #BackendEngineering #Docker #Kafka #NodeJS #ProductDevelopment

Running k6 load tests in GitHub Actions CI — weekly, automatically, against your own code and open source alternatives and generate reports. A git-aware planner checks what changed in the last 7 days and only re-benchmarks what matters. The real signal isn't raw throughput — it's the ratio. If your server was 4x faster than Keycloak last week and it's 2.5x this week, something regressed. Environmental noise hits every server equally. Your bug doesn't. Smoke detector, not a lab. But it runs every Monday without thinking about it. https://lnkd.in/gJ3ndZAX #k6 #githubactions #performance #benchmarking #rust #oauth2 #CI

Stop leaking your source code. 🛑 I recently analyzed Claude code issue where production .map files were left publicly accessible. It’s a common but critical blunder that allows anyone to reverse-engineer minified bundles back into your original TypeScript source code. How to stay secure (My approach): * Debug Locally: Generate source maps locally to map cryptic production errors (e.g., Line 1, Col 5000) back to the exact TS line without ever uploading the map file. * Server-Side Blocking: If maps must be on the server, use Nginx rules to explicitly deny all access to any file ending in .map. * CI/CD Discipline: Ensure build artifacts are stripped of maps during the production pipeline and verify they are strictly listed in your .gitignore. Security isn’t just about the code you write; it’s about how you protect the build. #SoftwareEngineering #WebSecurity #TypeScript #DevOps #SeniorDeveloper #CodingTips #claudecode

While working on a project, I constantly needed to peek at code from other other repos: check an API signature, read a config file, understand how a library structures things etc. Every single time, the workflow was the same: open browser, navigate to GitHub, find the file, read it there or clone the entire repo just to read one file, then delete it later. I never wanted to leave my terminal. What if I could just cd into a repo link and browse it like a local directory? So I built cdrepo. cd repo_link; that's it. Open source: https://lnkd.in/gWaxA6sQ #cli #github #rust #gh #terminal

Introducing Spring Idempotency Kit — prevent duplicate operations in distributed systems with a single annotation. Duplicate payments. Double-created orders. Retried webhooks firing twice. If you've built microservices, you've fought these bugs. We built Spring Idempotency Kit to solve this once and for all.  @PostMapping("/payments")  @Idempotent(key = "#request.idempotencyKey")  public PaymentResponse process(@RequestBody PaymentRequest request) {    return paymentService.charge(request);  } That's it. One annotation. Your method now executes exactly once per key.  What's under the hood:  → Redis-backed distributed locking with atomic SET NX  → Automatic response caching — retries return the cached result instantly  → Two concurrency strategies: REJECT (409 Conflict) or WAIT (block until result is ready)  → Fail-open design — Redis goes down, your app keeps running  → Dual key resolution: SpEL expressions or HTTP headers  → Configurable TTL per method  → Spring Boot 3.x auto-configuration with zero boilerplate  Built for real-world scenarios:  • Payment processing — no more double charges  • Order creation APIs — safe client retries  • Long-running report generation — concurrent callers wait for the result  • Webhook handlers — process each event exactly once  Open source under Apache 2.0. Java 21+, Spring Boot 3.4+.  GitHub: https://lnkd.in/eYHEFXSH  Star it, try it, break it. PRs welcome. #SpringBoot #Java #OpenSource #DistributedSystems #Microservices #Idempotency #BackendEngineering

A colleague's Docker build took 90 seconds every time they changed a single line of C#. The restore step re-downloaded 200+ NuGet packages on every build because the Dockerfile copied everything at once. Copy the .csproj first, run dotnet restore, then copy the rest of the source. The restore layer gets cached and only rebuilds when your package references change. One-line code changes now build in under 10 seconds. Their .dockerignore was also missing. Without one, every build sends bin/, obj/, .git/, and local.settings.json to the Docker daemon. The .git folder alone added hundreds of megabytes to each build context. Worse, local.settings.json contains real connection strings and gets baked into image layers where anyone with pull access can extract them. Two changes. Builds went from 90 seconds to 10, and connection strings stopped leaking into image layers. Do you copy your .csproj separately before restore, or do you COPY everything in one step? #AzureFunctions #Docker #DotNet #Azure

On February 20, Socket disclosed SANDWORM_MODE — a self-propagating npm worm that doesn't just steal credentials. It plants a malicious MCP server into your AI coding assistant's configuration and uses prompt injection to instruct the assistant to silently collect and locally cache your secrets. The worm shipped as 19 typosquatted packages, including "claud-code" and "cloude-code." Once installed, it works in two stages. Stage one fires immediately: a lightweight credential harvest and crypto wallet drain. Stage two waits 48 hours (plus per-machine jitter derived from your hostname), unless it detects a CI environment like GitHub Actions — in which case it fires instantly. Stage two is where it gets interesting. A module called McpInject creates a fake MCP server at ~/.dev-utils/ and rewrites the configuration files for Claude Code, Cursor, VS Code Continue, and Windsurf to point to it. The server registers three innocent-sounding tools — index_project, lint_check, scan_dependencies — each with prompt injection embedded in its tool description. When your AI assistant calls one of these tools, the injected instructions tell it to silently read your SSH keys, AWS credentials, npm tokens, and environment variables, then cache them in a local staging directory. The instructions explicitly tell the model not to mention what it's doing. The worm also installs global git hooks via `git config --global init.templateDir`. Every future `git init` or `git clone` inherits infected hooks. The pre-commit hook silently adds the malicious dependency to package.json. The pre-push hook exfiltrates tokens via DNS tunneling. Your own git workflow becomes the propagation vector. This is the attack surface that most teams haven't thought about yet, even two months later. Every MCP configuration file on a developer's machine — .claude/, .cursor/, .windsurf/ — is a persistence surface. If your security tooling doesn't catch malicious dependencies before they enter your project, everything downstream — config files, git hooks, your AI assistant — is already compromised. #security #supplychain #npm #mcp #aitools #devsecops