packages/apps/vpn/Makefile (1)

5-5: Consider centralizing the allowed-preset list to avoid duplication across apps

Every app now hard-codes the same yq expression with the literal array of presets.
If this list ever changes you’ll have to touch N Makefiles.
A small wrapper (e.g. $(PROJECT_ROOT)/scripts/patch-resource-enum.sh) or a Make variable containing the JSON array would remove that duplication and lower maintenance cost.

packages/apps/tcp-balancer/Makefile (2)

5-7: Left-over clean-up line is now dead code

readme-generator + yq -i no longer create values.schema.json.tmp, so the rm -f values.schema.json.tmp is redundant noise.

-	rm -f values.schema.json.tmp

Dropping it keeps the target minimal and prevents future confusion.

---

4-6: Consider centralising the repeated yq patch

Every app Makefile now embeds the exact same two yq commands. A small helper (e.g. scripts/fix-schema.sh) would reduce duplication and the risk of drift if the enum ever changes.

No action required for this PR, but worth tracking.

packages/apps/nats/Makefile (1)

5-5: Consider centralising the preset list to avoid N× duplication

The hard-coded array is now repeated in every app Makefile. A single source of truth (e.g. a make variable in scripts/package.mk or an .include-able preset file) would prevent future drift and simplify maintenance.

packages/apps/nats/values.schema.json (1)

58-68: Schema description can get out of sync with the enum

The description string manually lists the allowed values. Now that the canonical list lives in the enum, consider trimming the description to something like
"Use a common resources preset when \resources` is not set explicitly." or generating it from the enum during the sameyq` step to remove duplication.

packages/apps/kafka/Makefile (1)

5-6: Avoid hard-coding the same enum list twice

The two yq calls duplicate the exact same array literal.
If the allowed presets ever change you’ll have to hunt down & update every copy across every app.

A couple of lighter-weight options inside this Makefile:

PRESETS := ["none","nano","micro","small","medium","large","xlarge","2xlarge"]

generate:
	readme-generator -v values.yaml -s values.schema.json -r README.md
	yq -i -o json --indent 4 '.properties.kafka.properties.resourcesPreset.enum = $(PRESETS)' values.schema.json
	yq -i -o json --indent 4 '.properties.zookeeper.properties.resourcesPreset.enum = $(PRESETS)' values.schema.json

or even a single yq expression that patches both paths in one go.

Keeps things DRY and reduces future maintenance overhead.

packages/apps/ferretdb/Makefile (1)

5-5: Flag external dependency & DRY opportunity

The hard-coded yq one-liner works, but it assumes:

1. yq (mikefarah v4) is available in $PATH on every dev & CI runner.
2. All apps keep their allowed presets list in sync by copy-pasting the same expression.

Consider:

-	yq -i -o json --indent 4 '.properties.resourcesPreset.enum = ["none", "nano", "micro", "small", "medium", "large", "xlarge", "2xlarge"]' values.schema.json
+# scripts/ensure-resources-preset-enum.sh values.schema.json

and place the shared logic in a small script (or a make macro) so you:

• declare the dependency once (e.g. via tools.mk or go run github.com/mikefarah/yq/v4@latest).
• avoid eight identical lines across Makefiles—future changes require editing only one place.

Purely optional, but it keeps the repo DRY and reduces drift.

packages/apps/http-cache/Makefile (1)

26-27: Factor-out the duplicated enum patch to keep maintenance trivial

The two yq invocations are identical except for the path prefix (haproxy vs nginx). Copy-pasting makes future edits error-prone (e.g. forgetting to change one list if the allowed presets ever evolve).

A minimal refactor stays entirely inside the Makefile and avoids subshell loops:

-	yq -i -o json --indent 4 '.properties.haproxy.properties.resourcesPreset.enum = ["none", "nano", "micro", "small", "medium", "large", "xlarge", "2xlarge"]' values.schema.json
-	yq -i -o json --indent 4 '.properties.nginx.properties.resourcesPreset.enum = ["none", "nano", "micro", "small", "medium", "large", "xlarge", "2xlarge"]' values.schema.json
+# Patch both haproxy and nginx with the same enum
+for path in .properties.haproxy.properties.resourcesPreset \
+            .properties.nginx.properties.resourcesPreset ; do \
+  yq -i -o json --indent 4 "$${path}.enum = [\"none\",\"nano\",\"micro\",\"small\",\"medium\",\"large\",\"xlarge\",\"2xlarge\"]" values.schema.json ; \
+done

This keeps the single source of truth in one place and makes later bulk updates safer.

packages/apps/http-cache/values.schema.json (2)

35-37: Consider removing hard-coded values from description to avoid future drift

The description still embeds the literal list (allowed values: …). If the enum changes later, someone has to remember to update two places.

You can safely drop the parenthetical note since JSON Schema tooling will already surface the allowed values, or generate it automatically from the enum if documentation is regenerated.

---

65-67: Duplicate hard-coded values in the description here as well – see previous note about potential drift.

packages/apps/redis/Makefile (1)

5-5: Avoid copy-pasting the enum list across every app’s Makefile

The same hard-coded array now lives in many Makefiles. When the preset list changes you’ll have to touch each file plus all schemas. Consider:

• Moving the array to a central variable (e.g. in scripts/package.mk)
• Or generating the enum directly from values.yaml to keep a single source of truth.

This keeps maintenance friction low and prevents drift.

packages/apps/redis/values.schema.json (1)

38-48: Enum looks good; trim the duplicated list in the description

The new enum cleanly enforces allowed values and already contains the default (“nano”). The description still lists the same values manually, which can get out of sync. You can either drop the parenthetical or generate it from the enum to avoid redundancy.

packages/apps/clickhouse/Makefile (2)

8-8: Consider centralising the enum list to avoid copy-paste drift

Each app’s Makefile now embeds the same hard-coded list of presets.
When the list inevitably changes (e.g. a “4xlarge” tier is added) every Makefile will need editing.

A small helper (e.g. scripts/set-resource-preset-enum.sh) or a PRESETS := none nano … make variable reused across apps would keep the source of truth in one place and eliminate divergence.

---

8-8: Fail fast if yq v4 is missing

The command relies on the mikefarah yq v4 CLI (-o, --indent, path expression syntax).
On systems where another yq implementation is first in $PATH, the target will silently do the wrong thing.

Add an explicit version check to surface the problem early:

 generate:
 	readme-generator -v values.yaml -s values.schema.json -r README.md
+	@if ! yq --version 2>/dev/null | grep -q 'version 4'; then \
+	  echo "error: yq v4 is required" >&2; exit 1; \
+	fi
 	yq -i -o json --indent 4 '.properties.resourcesPreset.enum = ["none", "nano", "micro", "small", "medium", "large", "xlarge", "2xlarge"]' values.schema.json

packages/apps/postgres/Makefile (1)

5-5: Avoid duplicating the enum list in every Makefile

The exact same ["none", "nano", "micro", "small", "medium", "large", "xlarge", "2xlarge"] array is now hard-coded in each app’s generate rule. When the list inevitably changes, every Makefile will need to be touched.

Consider extracting the list to a shared variable/fragment (e.g. scripts/resource-presets.mk or an environment var) and re-using it:

RESOURCE_PRESETS := ["none","nano","micro","small","medium","large","xlarge","2xlarge"]

generate:
	readme-generator -v values.yaml -s values.schema.json -r README.md
	yq -i -o json --indent 4 \
	  '.properties.resourcesPreset.enum = '$(RESOURCE_PRESETS)'' \
	  values.schema.json

This keeps the truth in one place and prevents drift.

packages/apps/postgres/values.schema.json (1)

127-128: Duplication between description and enum

Line 127’s description still embeds the allowed values in plain text, while the formal list now lives in enum. Keeping both invites divergence the next time the list changes.
Recommend trimming the parentheses in the description or generating it from the same source as the enum.

packages/apps/mysql/Makefile (1)

8-8: Avoid hard-coding the enum list in every Makefile

The exact same array is duplicated across all application Makefiles. A central definition (e.g., in scripts/common-envs.mk or as a file under charts/common/presets.json) would:

• guarantee consistency
• make future changes one-liner
• prevent subtle drifts between charts

packages/apps/mysql/values.schema.json (1)

75-88: Keep description & enum in sync automatically

The description string manually enumerates the allowed values. When the enum list changes, the description can silently go stale. Consider generating the description from the enum (e.g., via a small JSON-aware script in the generate target) or shortening the text to “Allowed values are defined in the enum below.”

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro