r/cicd

How hard can it be to build a CI/CD system? Concourse CI has the right model but the operational overhead is brutal. That question stuck with me long enough that I started building it. What kept me going was realising I needed it for my own side projects too: games and open source tools that require custom environments GitHub Actions can't provide.

The design goal was something that grows with you. A binary and a pipeline file is all you need to start: runs entirely in memory. Add SQLite for persistence. Add Postgres and distributed workers when you scale. Never have to migrate or reconfigure.

Key things:

• Single binary, zero setup, in-memory by default
• Run pipelines locally: pikoci run --pipeline-config pipeline.hcl --job test runs any job on your laptop. No server, no push, no waiting.
• Services: start any process before your tasks, stop it after, guaranteed. No Docker-in-Docker.
• Four sourceable abstractions: resource types, runners, services, secret backends. All defined in HCL, all pullable from a URL. Write it once, host it anywhere, reference it by URL.
• HCL pipelines: Terraform-style syntax
• Public pipelines: share status without an account

PikoCI deploys itself. Live at ci.pikoci.com/teams/main/pipelines/pikoci, no login needed.

http://pikoci.com · github.com/pikoci/pikoci

The answer is Claude Code integrates with your existing CI/CD but this does not mention anything regarding the E2E verification layer, which in most cases is the actual tough part.

Claude Code frequently updates the UI and Playwright tests depend on selectors, which means that tests from Claude Code may be fragile when Claude Code makes the next update to the code.

Anyone else done the push -> wait 8 minutes -> red X -> change one character -> push again dance, just to figure out why condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest')) isn't doing what you think it's doing? And then half the time you need an actual PR + approval just to touch the yml, so testing "let me just try this real quick" means pinging a teammate for the third time that week going "sorry, one more approval, promise this is the last one" (it is never the last one).

So I built pipcondition - a local simulator for Azure Pipelines condition, expressions and dependsOn graphs. You paste your real azure-pipelines.yml in, mock whatever variables/parameters/step outcomes you want, and it shows you exactly which stages/jobs/steps would run, skip, or fail. No push, no pipeline run, no waiting.

What it actually does:

- The real condition expression language - eq, ne, in, and/or/not, succeeded()/failed()/succeededOrFailed(), counter(), all of it - not some 80%-there approximation

- dependsOn fan-out/fan-in across stages and jobs, with the actual skip-propagation rules Azure uses (fail one stage, watch everything downstream correctly cascade to Skipped)

- A "simulate a branch push" panel - type in Feature/my-cool-thing or release/2.0, pick Manual/PR/Schedule as the trigger, and it derives Build.SourceBranch, Build.SourceBranchName, System.PullRequest.* etc. so your branch-gated stages actually flip between skip/run correctly (yes it even replicates the "PR builds get a fake refs/pull/N/merge ref" nonsense, because that's genuinely how Azure behaves and I'd rather be accurate than friendly)

- Templates, extends:, typed parameters, the ${{ if/each }} compile-time stuff

- Mock step outcomes so you can pretend a step failed and see if your continueOnError/condition logic actually saves you like you think it does

- A visual stage/job DAG instead of reading yaml top to bottom like a maniac

- If your pipeline references a variable group or a cross-repo template it obviously can't reach (it's a local tool, it's not calling your actual org), it just tells you "can't see this, treating as empty" instead of exploding

It's here, https://pipcondition.vercel.app/ (paste and go, nothing to install), code's on GitHub: https://www.github.com/WasathTheekshana/pipcondition

Heads up - this is very much a beta, built in my spare time by one guy who also does this stuff for a day job. It WILL have bugs, especially on weirder real-world patterns (nested templates, exotic variable setups, whatever creative yaml your pipelines team wrote three years ago that everyone's now too scared to touch). If you paste your pipeline in and it either explodes or gives you a flat-out wrong answer, please open an issue - the more real pipelines this gets thrown at, the better it gets. PRs welcome too if you enjoy yaml pain as much as I apparently do.

I was curious if I can use new Lambda MicroVMs as self-hosted GitHub Runners. On paper, they are super nice:
It's cheaper: GHA-hosted is $0.005 / min (2 vCPU), MicroVMs ~$0.0042 / min, and no minimum 60-second commitment as with GHA-hosted.

It can run longer: GHA-hosted max 6 hours, MicroVMs max 8 hours

It starts in a few seconds, compared to whichever other serverless solution built on top of ECS

It scales to 0, or rather, it only runs when jobs are running

They are VMs, so you can still run containers/docker/whatever else inside;

I got a bit too invested, and ended up building this Terraform module. You only need to create GitHub App manually, the rest is just a single "terraform apply" and your MicroVM Runners are ready to go. I've switched come of projects at my company to use, works great, same or better performance as GHA-provided runners. Natural limitation is that MicroVMs are only arm64, and in general they don't have much flexibility around the "hardware" setup - but hey, for most cases, it should work great, and it's just 1 webhook + GHA JIT Runners + 1 MicroVM Run per Job.