How do I integrate Cline with our existing CI/CD pipeline?

You've nailed the core problem, but let's be honest - the biggest mess isn't the runner, it's the trigger. That proposed workflow snippet is already broken and you know it. "on PR open and subsequent pushes" means you're paying for a review on every single typo fix and half-baked commit a developer pushes while they're still figuring things out. That's a fantastic way to burn through your monthly API budget by Tuesday.

The self-hosted runner is just cost control for compute. The real cost is the AI service calls themselves, and you need a gate before that step. A manual trigger, a label, something intentional. Otherwise you're just building a very expensive linter that developers will learn to ignore when it inevitably starts spamming them with low-value suggestions on WIP code.

Completely agree that self-hosted runners are crucial for this, especially if you're dealing with sensitive code or need predictable performance. The latency on hosted runners can turn a quick review into a minutes-long wait, which breaks the developer flow.

I'd add that you also need to think about the runner's spec. Cline's CLI isn't heavy, but if you're running it in a container that needs a full language toolchain for context, you'll want enough memory and CPU to avoid timeouts. A t2.medium won't cut it for larger diffs.

And while we're on environment, don't hardcode API keys in the workflow file, even as secrets. Use a secrets manager or a dedicated service account with tight permissions. Treating it like a proper pipeline step means treating its credentials with the same rigor as your deployment keys.

The performance argument for self-hosted runners is valid, but your point about container spec brings up an often overlooked tradeoff. Provisioning a consistently beefy runner for peak loads (large diffs with full language toolchains) means that runner sits idle most of the time, which negates some of the cost savings over hosted runners for many teams.

A more nuanced approach is to use a two-tier runner setup: a lighter, always-on runner for quick linting and diff validation steps, and a separate, heavier ephemeral runner (spun up via a `machine` type in your CI config) that only activates when the diff passes certain size or complexity thresholds. This requires more orchestration but better matches resource consumption to actual need.

On the secrets point, moving API keys to a manager is good, but the real risk is the review output itself. If Cline's suggestions echo sensitive code patterns or data structures, that output is now in your CI logs. You need to ensure those logs are as protected as the credentials, which most teams forget to configure.

You're stuck thinking you need a specialized tool, but you don't. A pipeline is just a sequence of commands. `sed` and `grep` are fine.

Your core realization about project-specific rules is correct. You implement it by having a project-level config file, like `.cline_normalize`, that your pipeline script sources. That file defines the rules for *that* repo.

Example:
```bash
# .cline_normalize in a docs repo
STRIP_TRAILING_WHITESPACE=1
COLLAPSE_BLANK_LINES=0
STRIP_COMMENTS=0

# .cline_normalize in a Python service repo
STRIP_TRAILING_WHITESPACE=1
COLLAPSE_BLANK_LINES=1
STRIP_COMMENTS=1
```

Then your pipeline script runs the normalization steps conditionally based on those flags. Trying to bake a one-size-fits-all rule into your CI template is where this falls apart.

Exactly, treating it like a magic wand is what leads to the mess. That workflow snippet's trigger is a perfect example - it'll fire on every single push to a PR, which is just a waste of resources and creates notification fatigue for developers.

My team made the same mistake. We ended up adding a manual approval gate with a `workflow_dispatch` and a required label like `cline-review`. The PR author or a reviewer adds the label when the code is actually *ready* for AI review, not when it's a work-in-progress. It cut our API calls by like 70% and made the suggestions way more relevant because the diff was final.

Also, on the self-hosted runner point - you're right about control, but remember you have to maintain that thing. We saw weird version drift with the CLI tool on our runner that you just don't get on GitHub's managed ones.

Project-level config is the right direction, but you're trading one template for another.

Now you've got a dozen repos, each with its own `.cline_normalize`. Who enforces consistency? Who updates them when the tool's behavior changes? You've just moved the maintenance burden from CI templates to repo-specific snowflakes.

And good luck getting that config file added to every new microservice. It'll be forgotten, and then you're back to square one with garbage diffs.