apiVersion: helm-expt.confighub.com/v1alpha1
kind: HelmCatalogDemoReadme
metadata:
  name: readme
  labels:
    app.kubernetes.io/part-of: helm-catalog
    helm-expt.confighub.com/space: "bitnami-redis-staging"
    helm-expt.confighub.com/readme-kind: "environment"
spec:
  space: "bitnami-redis-staging"
  title: "Redis staging application"
  summary: "A staging variant that keeps a local replica choice while the Redis base moves forward."
  sourcePath: "data/helm-catalog-readmes/spaces/bitnami-redis-staging/README.md"
  links:
    - label: "Benchmark: upgrade keeps edit"
      url: "https://github.com/confighub/helm-expt/blob/main/data/pilot-benchmark/task1-upgrade-keeps-edit.md"
    - label: "Promote proof notes"
      url: "https://github.com/confighub/helm-expt/blob/main/runs/promote-silent-skip-proof/README.md"
  markdown: |-
    <!-- Generated by npm run helm-catalog-readmes. Do not edit by hand. -->

    # Redis staging application

    A staging variant that keeps a local replica choice while the Redis base moves forward.

    Start here when you open this Space in Hub. This page explains the problem this example is meant to show, what to inspect, why it matters, and where the evidence lives.

    ## Why this example exists

    This is the everyday Helm problem: a team needs one environment to differ from the base, then needs the next chart upgrade not to wipe that difference.

    ConfigHub makes the local decision visible and keeps it during upgrade.

    ## What this example shows

    - Staging can carry its own change, such as a different replica count, while still receiving a base upgrade.
    - The local change is a recorded revision, not a remembered Helm flag or a local values file that can be lost.

    ## Where each setting comes from

    | Place | What this Space records |
    | --- | --- |
    | Starting configuration | The upstream link points to `bitnami-redis-base`, which holds the Helm-rendered Redis objects. |
    | ConfigHub changes | This Space sets namespace `redis-staging` and records `spec.replicas: 2` on the Redis replica StatefulSet. The replica revision remains after the base is upgraded. |
    | Install work | Prerequisites come from the selected Redis base. The staging replica choice is not a Helm hook or prerequisite. |
    | Live cluster | The benchmark observed two replicas after the 27.0.0 upgrade. That observation checks the recorded setting; it is not another source of it. |

    If an upstream change and a local ConfigHub revision touch the same field, review the overlap before promotion.

    ## What to inspect in Hub

    - This README.
    - The Redis StatefulSet YAML and its revision history.
    - `bitnami-redis-base` for the upstream base.

    ## Evidence and source

    - [Benchmark: upgrade keeps edit](https://github.com/confighub/helm-expt/blob/main/data/pilot-benchmark/task1-upgrade-keeps-edit.md)
    - [Promote proof notes](https://github.com/confighub/helm-expt/blob/main/runs/promote-silent-skip-proof/README.md)

    ## Limits

    - One map-shaped conflict in the promotion proof is still silent and is documented as a product issue.