# Add a NetworkPolicy Option to a Helm Chart from a Linear Issue

Yes. An agent picks up the Linear issue, adds a NetworkPolicy option with configurable ingress sources, unit tests and a chart version bump.

[Run this on Rush](https://cloud.getrush.ai/run/add-network-policy/helm/), in a Project that has your repository.

## What the agent does

The run starts from the repository URL in `resources`: the agent clones it into its own cloud sandbox and opens the chart the issue names. In `prometheus-community/helm-charts`, that chart is `charts/prometheus-blackbox-exporter/`. `Chart.yaml` reports version 11.20.0 and appVersion `v0.29.0`, with kubeVersion `>=1.21.0-0`. Templates already include `templates/networkpolicy.yaml`, and `values.yaml` has a `networkPolicy` block with `enabled: false`, `allowMonitoringNamespace` and `monitoringNamespaceName`.

The existing NetworkPolicy is narrow. When enabled without `allowMonitoringNamespace`, the template emits an ingress rule of `{}` (allow all). When `allowMonitoringNamespace` is true, it allows only pods from the namespace labelled `kubernetes.io/metadata.name` matching `monitoringNamespaceName`. There is no list of arbitrary ingress sources, and the blackbox chart has no `tests/*.yaml` unit suite yet (unlike sibling charts such as `prometheus-ipmi-exporter/tests/`). CI values under `ci/networkpolicy-values.yaml` only set `enabled: true`.

The agent extends `networkPolicy` with a configurable ingress sources list (namespace selectors and optional pod selectors) that the template renders when `enabled` is true, keeps the monitoring-namespace shortcut working, and defaults `enabled` to false so installs do not change behaviour. It adds helm-unittest specs that assert no NetworkPolicy when disabled, and that enabled values render only the configured sources. `Chart.yaml` version bumps per the repository's chart release practice.

Proving it means the commands the issue names: `helm lint` on the chart, chart-testing (`ct lint`) against the repo's config, and `helm unittest` for the new specs. The agent runs those in the sandbox and fixes template whitespace or values schema issues they surface.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "A Linear issue labeled agent says: \"Add a NetworkPolicy Option to a Helm Chart. Add networkPolicy.enabled to the prometheus-blackbox-exporter chart, rendering a NetworkPolicy that allows only the configured ingress sources, with unit tests and a chart version bump.\" Do the work in this repository, add tests for it, run helm lint, ct lint and helm unittest, and open a pull request that links back to the issue.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request. Its diff updates `charts/prometheus-blackbox-exporter/values.yaml` and `templates/networkpolicy.yaml`, adds unittest files under that chart, bumps `Chart.yaml`, and may refresh `ci/networkpolicy-values.yaml`. The description quotes the issue and links back to it.

The checks on the pull request run `helm lint`, `ct lint` and `helm unittest`. A reviewer reads the default (`enabled: false`), confirms enabled installs no longer rely on an empty allow-all rule when sources are set, and confirms the version bump matches the changelog expectations for the repo. Other exporter charts are untouched.

The session read keeps the record behind the pull request: lint output and the unittest results. Anyone who questions an ingress from stanza can open the rendered fixture the agent asserted on.

## Run it on every Linear issue labelled agent

The Project's automation turns the label into the run. In the console, add an automation with a Linear trigger on `linear.issue.labeled` filtered to the `agent` label and this prompt; each labelled chart security issue starts its own run in its own sandbox and opens its own pull request on the helm-charts repository.

If the automation is not wanted, a small server can do the same: receive Linear's issue webhook, put the issue text into `input`, and POST to `/o/{org}/sessions` with the prometheus-community helm-charts repository in `resources`. A `run.completed` webhook on the API key posts the pull request when ct lint and unittest finish.

## Why run it on Rush?

On a laptop this job needs Helm, chart-testing and helm-unittest plugins at versions the CI workflows expect, plus a checkout large enough to hold every chart. Each run on Rush boots its own sandbox with that already in reach, runs lint and unittest itself, and keeps every command and its output.

NetworkPolicy changes are easy to get wrong in a shared charts monorepo. Labelling the issue gives blackbox-exporter its own sandbox so a values rename does not collide with someone bumping kube-prometheus-stack on the same machine.

## Frequently asked questions

### networkPolicy.enabled already exists in values.yaml. What is left?

The flag and template exist, but enabled mode can allow all ingress, and there are no unit tests. The agent adds configurable ingress sources, asserts them with helm-unittest, and bumps the chart version.

### Does enabling the policy break Prometheus scrapes?

Only if the configured sources omit the scrape namespace. The monitoring-namespace shortcut and the new sources list are how you allow Prometheus; the default stays disabled so upgrades are safe.

### Which chart version gets bumped?

The `version` field in `charts/prometheus-blackbox-exporter/Chart.yaml` (11.20.0 at clone time). `appVersion` stays tied to the blackbox_exporter release unless the issue asks otherwise.

### Are Kubernetes integration tests required?

No. The issue asks for unit tests with helm-unittest and lint via helm and ct. Cluster install tests are out of scope unless CI already runs them for this chart.