feat: add values.schema.json for service and cron-job charts

[arunesh-j]

Summary

Adds values.schema.json (JSON Schema draft-07) for the service and cron-job charts, following the format used by the existing charts in this repo (e.g. mariadb). These schemas drive the editable form fields rendered by the form manager, which fetches charts/<name>/values.schema.json directly from the main branch (no chart release/version bump required).

Two commits, one per file:

• feat(service): add values.schema.json for service chart
• feat(cron-job): add values.schema.json for cron-job chart

Scope of fields

The schemas describe only the user-configurable values surfaced in the UI. Each editable field is annotated with "mutable": true (a real boolean), and name is intentionally left non-mutable.

• service: name, image, httpPort, metricsPort, ports, nginx, envFrom, minCPU/minMemory/maxCPU/maxMemory, minReplicas/maxReplicas, hpa_enable/hpaCPU/hpaMemory, heartbeatURL, readinessProbe, livenessProbe, env, envList, appSecrets, command, alerts
• cron-job: name, image, schedule, suspend, concurrencyPolicy, command, httpPort, metricsPort, minCPU/minMemory/maxCPU/maxMemory, envFrom, env, envList, appSecrets, alerts

Advanced/internal keys (keda, securityContext, initContainer, datastores, imagePullSecrets, volumeMounts, etc.) are intentionally omitted. Since neither schema sets additionalProperties: false, those keys remain fully valid and functional — they are simply not schema-validated or rendered as form fields.

Notes on typing

• Keys that default to null in values.yaml accept "null" in their type so the shipped defaults pass Helm validation.
• hpaCPU/hpaMemory are typed as string|null (the hpa.yaml template compares them to "" and nil, so an integer breaks rendering).
• CPU/memory use pattern regexes consistent with the mariadb schema.
• Top-level required: ["name", "image"]; nested required arrays are scoped to their objects and only fire when those optional sections are populated.

Verification

• Both files are valid JSON
• helm lint passes for both charts
• helm template renders both with default values.yaml
• helm template renders both with every schema field set to a realistic value, and the values flow through to the manifests (Deployment/HPA/Ingress/PrometheusRule for service; CronJob/PrometheusRule for cron-job)
• Negative cases rejected as expected (bad serviceType/concurrencyPolicy enums, missing required fields)

[PiyushSingh-ZS]

Reviewed against the diff, both charts' values.yaml + templates, and the reference schema (mariadb). Solid PR — both schemas follow the repo's established convention well. A few notes.

Alignment with the mariadb reference ✅

• draft-07 header, mutable: true on editable leaves (not on name), CPU/memory pattern regexes identical to mariadb, and no additionalProperties: false (advanced keys stay valid) — all consistent.
• Deviation: this PR adds a top-level required: ["name","image"]; mariadb has no top-level required. Harmless since both are non-mutable and always shipped — just flagging the departure from the reference.

Verified correct against the templates 👍

• cron-job command: cronJob.yaml:63 emits command: {{ tpl (toJson .Values.command) . }}. The not: { type: string, minLength: 1 } constraint correctly forbids a non-empty string (which would render command: "foo" — invalid for a k8s []string) while still permitting the shipped "" default. Nice.
• service command: same toJson pattern at deployment.yaml:125; schema types it ["array","null"] (no string), safe given its null default. The asymmetry with cron-job is correct — each matches its own default.
• hpaCPU/hpaMemory as ["string","null"]: matches the ne "" / ne nil guards in hpa.yaml:20-36. Minor doc nit: the PR description says "typed as string" — they're actually string|null.
• service metricsPort (no default): correct — service values.yaml ships none, and templates gate on (ne (int .Values.metricsPort) 0).

Worth confirming

A few user-facing service keys are consumed by templates but omitted from the schema: replicaCount, minAvailable (PDB), metricsScrapeInterval, injectIstio, cliService. If the scope is strictly "fields the form manager renders," that's a fine call — just confirming each omission is deliberate.

[arunesh-j]

Thanks for the thorough review, @PiyushSingh-ZS. Responding to each point:

Omitted service keys — deliberate. Scope is strictly "fields the form manager renders as editable", so minAvailable (PDB), metricsScrapeInterval, injectIstio, and cliService are intentionally left out. They remain fully functional via raw values since neither schema sets additionalProperties: false — they're just not surfaced as form fields.

One clarification: replicaCount is actually not consumed by any template — the Deployment sets replicas: {{ .Values.minReplicas }} (deployment.yaml:18). So its omission isn't just a scoping call; it's a dead value. Replica count is driven by minReplicas/maxReplicas, which are in the schema.

Top-level required: ["name","image"] vs mariadb. Intentional departure. Both are always shipped and are mandatory for the chart to render a valid manifest (metadata.name, container image), so required just turns a would-be downstream render failure into an early, clear validation error. Happy to drop it to match the reference if you'd prefer strict alignment.

Doc nit (hpaCPU/hpaMemory). Fixed — the PR description now reads string|null.

[PiyushSingh-ZS]

Thanks for the detailed responses — all points addressed. Confirmed replicaCount is indeed unused (only in values.yaml/README, never a template; deployment.yaml:18 uses minReplicas), so the omission is correct. Keep the top-level required: ["name","image"] — turning a downstream render failure into an early validation error is the better call. LGTM 🚀