Add Resource Requests and Limits to a Kustomize App from a Linear Issue

The agent starts from the Linear issue and the repository in its own cloud sandbox, and takes an inventory before it edits a manifest. In a GitOps repository shaped like argoproj/argocd-example-apps, sock-shop/kustomization.yaml lists 29 files under base/: 14 Deployments, 14 Services and one Ingress for sockshop.apps.argoproj.io. Eight of the Deployments already carry a resources block, and they are not uniform: carts, queue-master and shipping ask for and cap at 300m CPU and 500Mi memory, catalogue at 100m and 100Mi, front-end requests 100m and 300Mi under limits of 300m and 1000Mi, orders requests 200m under a 500m limit, payment requests 99m under 100m, and user requests 100m CPU under 300m with 100Mi both ways. The other six have none: carts-db, orders-db and session-db (the mongo and redis:alpine images), catalogue-db, user-db, and rabbitmq, which also runs a kbudde/rabbitmq-exporter sidecar with no resources of its own, so there are seven containers to change. The smaller kustomize-guestbook app has one Deployment of gcr.io/google-samples/gb-frontend:v5 with nothing set either.

The agent then decides where the change goes. sock-shop has no overlays; its kustomization.yaml names the base files directly, so a patches block would be a second place to look for a value that belongs in one. It edits each Deployment under sock-shop/base/ in place and keeps the diff to the resources block. Where an app does have overlays, as kustomize-guestbook would after a staging overlay is added, it writes a strategic merge patch in the overlay instead, so the base stays environment-neutral. The values come from the issue when it gives them; when it gives none, the agent starts each container at the smallest tier already in the app, 100m CPU and 100Mi memory as catalogue and payment use, with requests equal to limits so the pod lands in the Guaranteed QoS class like carts and shipping, and the pull request says plainly that these are starting points to be tuned from metrics, not measured numbers. For carts it also notes the existing JAVA_OPTS of -Xmx128m against a 500Mi limit, since the heap cap and the container cap should be read together.

Then it renders and checks. kustomize build sock-shop must still produce all 29 resources with the new blocks in place and nothing else changed, and the agent diffs that output against a build of the base branch to show the change is only what it meant. It runs kubeconform -strict -summary over the rendered YAML so a misplaced key such as resources at the pod level rather than the container level is caught, and where a kind cluster is available in the sandbox it applies the output with kubectl apply --dry-run=server to let the API server validate the quantities. The repository has no CI of its own, so these three commands are the checks, and their output goes into the pull request.

The pull request also carries a table: one row per container, with the image, the requests and limits before and after, and the QoS class the pod will get. Containers that were already set are listed as unchanged, so a reviewer sees the whole app, not only the diff.

What comes back is a pull request on its own branch that touches only the Deployment files for containers that had no resources block, in sock-shop/base/ six files covering seven containers. The description links the Linear issue, carries the per-container table with the before and after values and QoS class, and quotes the kustomize build diff summary, the kubeconform summary line and, when a cluster was available, the dry-run output.

The transcript at GET /o/{org}/sessions/{id}/messages keeps each kustomize build, the diff and the validation runs with their full output, and GET /o/{org}/p/{project}/sessions/{id}/changes lists each changed file with its diff. A rendered output that fails validation ends the run needs_review instead of a pull request that claims the manifests are valid.

Before merging, a reviewer checks the starting values against what the cluster's metrics show for those pods, confirms no LimitRange or ResourceQuota in the target namespace rejects them, and reads the rabbitmq change twice because that pod has two containers. Argo CD picks the change up on sync; a follow-up on the same session can raise a value once the first sync has run for a day.

In the console, add an automation to the Project with this prompt and a linear trigger on linear.issue.labeled, filtered to the agent label and to the platform team. When someone labels an issue such as "sock-shop databases have no resource limits, pods get evicted first under pressure", the trigger puts the issue after the prompt and the run scopes itself to the app the issue names, with the values it gives. Only label changes made by a person in your Rush org fire the trigger, and the automation starts at most max_runs_per_hour runs in an hour.

From your own server, the same body goes to POST /o/{org}/sessions with the repository in resources and the issue's URL beside it, read through your Linear connection, and a request_id made from the issue id so a retried call returns the run already started rather than opening a second pull request.

Resource blocks are easy to type and easy to put in the wrong place, and a GitOps repository with no CI finds out at sync time. In its own sandbox the agent renders the app with the same kustomize Argo CD runs, validates the output with kubeconform, and keeps the diff against the base branch, so the pull request shows that the only change is the one the issue asked for.

Several apps can run at once, each in a separate sandbox and a separate pull request, and every command is in the transcript. A reviewer who wants to know why a value was chosen reads the table and the issue, not a commit message.

Where do the numbers come from?

Does it edit the base or add a patch?

What about sidecars?

Can it validate without a cluster?