feat(k8s-reporter): stop passing the scaling flags

[ToreMerkely]

Chart half of #1061.

reporterConfig.includeScaling exists only to pass --include-scaling / --exclude-scaling to the CLI, and only when autoEnvironment is true — i.e. only on the environment-creation path. Server-side, kosli-dev/server#6332 made scaling capture a one-way ratchet: Environments.create hard-codes include_scaling: False, so a new environment never captures scaling regardless of what is sent. Both flags were therefore already inert in the chart's only code path, buying nothing but a CLI deprecation warning in the reporter's logs every run.

This PR stops passing them.

• templates/cronjob.yaml — the includeScaling branch removed; no scaling flag is emitted for true, false, or unset
• values.yaml — value marked Deprecated and ignored. Also drops the stale "Leave unset to use the Kosli server default" and the (server default) default annotation, neither of which is true any more
• _templates.gotmpl — body.deprecatedIncludeScaling rewritten, shared by the README upgrade section and (via _mintlify_templates.gotmpl) the Mintlify upgrade page
• Chart.yaml 2.6.0 → 2.7.0, README.md regenerated with make helm-docs

make helm-lint passes.

Why 2.7.0 and not a major

No user can observe a difference:

includeScaling	Before	After	Difference
unset (default)	no flag passed (kindIs "bool" is false for null)	no flag passed	none
true	--include-scaling → server ignores it, env created scaling-off	no flag → env created scaling-off	none, minus a log warning
false	--exclude-scaling → env created scaling-off	no flag → env created scaling-off	none

The knob was already inert before this PR; the chart is catching up with reality rather than changing behaviour. This chart's 2.0.0 set the precedent that a major means migration work — it required every user to rewrite their values into the environments list. This needs no action from anyone, and a major would strand users pinned to ^2 for nothing.

reporterConfig.includeScaling stays declared so the deprecation is discoverable; deleting it waits for a real major.

Checklist

• Docs are autogenerated from CLI help — make sure the help text reflects your changes
• Helm chart (charts/k8s-reporter/) updated, if needed. Note: these changes live in a separate PR
• Terraform provider and related changes (terraform-provider-kosli, terraform-aws-evidence-reporter, terraform-aws-kosli-reporter) updated, if needed — n/a: the provider removed include_scaling under its own issue fix description value in create flow #235 and only keeps regression tests asserting its absence; neither reporter module references scaling

🤖 Generated with Claude Code

[claude]

Claude finished @ToreMerkely's task in 1m 55s —— View job

---

Review

Chart-only PR. Go static analysis (go build / go vet / go mod tidy) is n/a — no Go files touched. Couldn't run helm lint/helm template (helm not in this job's command allowlist), so template correctness below is by inspection; the author reports make helm-lint passes.

• Read the diff
• Verify template logic in cronjob.yaml
• Verify docs regeneration consistency (README vs templates)
• Post review

Template correctness ✅

The removed block in templates/cronjob.yaml was fully self-contained inside the autoEnvironment branch. After removal the block is well-formed — two {{- end }} remain, closing environmentDescription (117-118) and autoEnvironment (113-119). No dangling end, no orphaned flag. The kindIs "bool" guard that used to distinguish unset/true/false is gone along with the only consumer, so nothing else depends on it. Good, minimal cut.

Docs consistency ✅

• Prose is DRY'd through the single body.deprecatedIncludeScaling define, shared by the README (extra.upgrade) and the Mintlify page (_mintlify_templates.gotmpl) — both {{ template ... }} the same block. 👍
• The values.yaml comment and the README.md table row match verbatim, as helm-docs requires. The @default annotation correctly dropped (server default), and README.md reflects the regeneration. This is exactly the "must be updated together" caveat from note 2 being honoured.
• Heading-level (## Mintlify vs ### README) and ordering differences are intentional per the earlier triage — no concern.

One correctness nit (non-blocking, your call — already debated)

The shared prose and the values.yaml/README table both assert, unscoped:

Scaling events do not trigger new snapshots [...] and an environment can no longer have scaling capture turned on

I see this was raised on _templates.gotmpl:25 and you replied NO, so I won't reopen the thread — just recording my independent read since text accuracy is the whole point of this PR. The second clause ("can no longer have scaling capture turned on") is precise and matches the ratchet. The first clause is the one that reads as universal: per this PR's own description, grandfathered environments that already capture scaling still record scaling events, so "scaling events do not trigger new snapshots" is only true for the environments this value ever touched (newly auto-created ones). It's the same shape as the "scaling events no longer create environment snapshots" claim you deliberately corrected on #1061. Scoping it (e.g. "for an environment this chart auto-creates, …") would keep it honest for readers on grandfathered environments. Entirely your judgement — flagging once, not blocking.

Minor: the prose says "do not trigger" while the table row says "no longer trigger" — harmless wording drift, not worth a churn.

Semver

The 2.7.0 (minor) reasoning is sound and well-documented: the flags were already inert server-side, so no observable behaviour changes and pinning to ^2 shouldn't break. Keeping the value declared for discoverability rather than deleting it is the right call for a minor. The v3 heading question from @mbevc1 was resolved cleanly by dropping the version-specific removal promise.

Verdict

Well-scoped, well-reasoned, and the migration story is clearly documented. LGTM aside from the single non-blocking text nit above.
• 6327-deprecate-scaling-chart

[ToreMerkely]

Triage of the review notes.

Not raised here, but found while tracing note 2 — fixed in d18105f.

The chart text repeated a claim that was corrected on #1061 in d82aa7a: "scaling events no longer create environment snapshots." That is false for the grandfathered environments that still capture scaling — the ratchet in kosli-dev/server#6332 stopped scaling being turned on, it did not stop environments that already have it from capturing.

Two adjacent claims were worse:

• "The value still works." It did not. The chart passes the flags only when autoEnvironment is true, and the CLI applies them only in createEnvironmentForSnapshot — the new-environment path. Server-side Environments.create hard-codes include_scaling: False. So both flags were inert in the chart's only code path.
• "Leave unset to use the Kosli server default", plus the @default -- \null` (server default)` annotation rendering into the README table. There is no server default to fall back to any more.

Since the value could no longer do anything, the PR now also stops passing the flags rather than passing them and warning about it. Retitled and rescoped to 3.0.0; see the updated description.

Note 1 — heading level and placement differ between the two docs. Skipping.

The ### vs ## difference is correct rather than accidental: the Mintlify upgrade page is standalone, so ## is its top level, while the README nests the section under ## Upgrading the chart. Only the ordering relative to the upgrade command genuinely differs, and normalising it would churn both templates for no reader benefit.

Note 2 — wording duplicated between values.yaml and the partial. Acted on.

The caveat ("both must be updated together if the wording changes") came due immediately. Both were rewritten in the same commit. Agreed it cannot be DRY'd — helm-docs needs the comment for the table and the partial for the prose.

Note 3 — 3.0.0 tracking issue. Skipping, per maintainer call. The chart docs and this PR already record that the value is going away.

[ToreMerkely]

Triage of the review against 9ff9a7dd. The branch has moved on twice since — now at 2d4abb64.

Open item (mbevc1's "removed in v3") — addressed in afa7b50.

Both headings now read Deprecated and ignored in v2.7.0, which was the substance of the note: "Deprecated" alone understated a value that is inert, and it contradicted the values.yaml table row already reading Deprecated and ignored.

Went the other way on naming a version, though. You flagged that the table row names none and asked whether it should say v3 for consistency — the resolution is the reverse: no version is named anywhere. The body keeps "a future major version" rather than committing the chart to deleting the value in a specific release. Consistency preserved, without a promise in published docs that is easier to make than to keep.

Also since this review: appVersion bumped v2.34.0 → v2.36.1 in 2d4abb6, at mbevc1's request. It is the default image tag and is only ever touched when someone edits the chart, so it had drifted three releases behind. Note it does not contain the CLI-side deprecation from #1061, which is unmerged — that does not matter here, since the chart no longer passes the flags.

On the clause you declined to re-litigate — agreed, and thanks for not. Reaction added so a future review pass skips it.

Everything else in the review was confirmation rather than a finding, so nothing further outstanding on this branch.