`redis/23.1.1` Git tag does not match published `redis` Helm chart `23.1.1`

[nicholasmhughes]

Name and Version

bitnami/redis 23.1.1

What steps will reproduce the bug?

Actual behavior

For the same chart version, 23.1.1:

• GitHub tag redis/23.1.1 resolves to commit e3296a831406bacf5ce661c5274590d0b40efcdd.
• The tagged source has appVersion: 8.2.1.
• The tagged source has AOF-only default commonConfiguration.
• The published Helm chart artifact has appVersion: 8.2.2.
• The published Helm chart artifact includes fips: "true" metadata and common dependency 2.32.3.
• The published Helm chart artifact includes RedisSearch/ReJSON loadmodule lines in default commonConfiguration.

Commands used to capture evidence

1. Confirm the remote GitHub tag SHA

$ git -C github/bitnami/charts ls-remote --tags origin 'refs/tags/redis/23.1.1'
e3296a831406bacf5ce661c5274590d0b40efcdd	refs/tags/redis/23.1.1

2. Confirm the local tag resolves to the same commit

$ git -C github/bitnami/charts rev-parse redis/23.1.1^{commit}
e3296a831406bacf5ce661c5274590d0b40efcdd

3. Inspect Chart.yaml from the Git tag

$ git -C github/bitnami/charts show redis/23.1.1:bitnami/redis/Chart.yaml | rg -n "appVersion|version:|redis:|redis-sentinel|common"
11:      image: docker.io/bitnami/redis:8.2.1-debian-12-r0
14:    - name: redis-sentinel
15:      image: docker.io/bitnami/redis-sentinel:8.2.1-debian-12-r0
19:appVersion: 8.2.1
21:- name: common
24:  - bitnami-common
25:  version: 2.x.x
41:version: 23.1.1

4. Inspect commonConfiguration from the Git tag

$ git -C github/bitnami/charts show redis/23.1.1:bitnami/redis/values.yaml | sed -n '190,205p'
    ## @param auth.acl.userSecret Name of the Secret, containing user credentials for ACL users. Keys must match usernames.
    userSecret: ""
## @param commonConfiguration [string] Common configuration to be added into the ConfigMap
## ref: https://redis.io/topics/config
##
commonConfiguration: |-
  # Enable AOF https://redis.io/topics/persistence#append-only-file
  appendonly yes
  # Disable RDB persistence, AOF persistence already enabled.
  save ""
## @param existingConfigmap The name of an existing ConfigMap with your custom configuration for Redis(R) nodes
##
existingConfigmap: ""
## @section Redis(R) master configuration parameters
##
master:

5. Inspect Chart.yaml from the published Helm repository

$ helm show chart redis --repo https://charts.bitnami.com/bitnami --version 23.1.1 | rg -n "appVersion|version:|redis:|redis-sentinel|common|fips"
2:  fips: "true"
5:      version: 1.34.1
8:      version: "5"
11:      version: 8.2.2
12:      image: registry-1.docker.io/bitnami/redis:latest
14:      version: 1.78.0
16:    - name: redis-sentinel
17:      version: 8.2.2
18:      image: registry-1.docker.io/bitnami/redis-sentinel:latest
22:appVersion: 8.2.2
24:- name: common
27:  - bitnami-common
28:  version: 2.32.3
44:version: 23.1.1

6. Inspect commonConfiguration from the published Helm repository

$ helm show values redis --repo https://charts.bitnami.com/bitnami --version 23.1.1 | sed -n '190,205p'
    ## @param auth.acl.userSecret Name of the Secret, containing user credentials for ACL users. Keys must match usernames.
    userSecret: ""
## @param commonConfiguration [string] Common configuration to be added into the ConfigMap
## ref: https://redis.io/topics/config
##
commonConfiguration: |-
  # Enable ReJSON y Redisearch
  loadmodule /opt/bitnami/redis/lib/redis/modules/redisearch.so
  loadmodule /opt/bitnami/redis/lib/redis/modules/rejson.so
  # Enable AOF https://redis.io/topics/persistence#append-only-file
  appendonly yes
  # Disable RDB persistence, AOF persistence already enabled.
  save ""
## @param existingConfigmap The name of an existing ConfigMap with your custom configuration for Redis(R) nodes
##
existingConfigmap: ""

7. Confirm the downloaded dependency tarball matches the published Helm repository behavior

These commands were run against the tarball produced by:

$ helm dependency update .

$ tar -xOzf charts/redis-23.1.1.tgz redis/Chart.yaml | rg -n "appVersion|version:|redis:|redis-sentinel|common|fips"
2:  fips: "true"
5:      version: 1.34.1
8:      version: "5"
11:      version: 8.2.2
12:      image: registry-1.docker.io/bitnami/redis:latest
14:      version: 1.78.0
16:    - name: redis-sentinel
17:      version: 8.2.2
18:      image: registry-1.docker.io/bitnami/redis-sentinel:latest
22:appVersion: 8.2.2
24:- name: common
27:  - bitnami-common
28:  version: 2.32.3
42:version: 23.1.1

$ tar -xOzf charts/redis-23.1.1.tgz redis/values.yaml | sed -n '190,205p'
    ## @param auth.acl.userSecret Name of the Secret, containing user credentials for ACL users. Keys must match usernames.
    userSecret: ""
## @param commonConfiguration [string] Common configuration to be added into the ConfigMap
## ref: https://redis.io/topics/config
##
commonConfiguration: |-
  # Enable ReJSON y Redisearch
  loadmodule /opt/bitnami/redis/lib/redis/modules/redisearch.so
  loadmodule /opt/bitnami/redis/lib/redis/modules/rejson.so
  # Enable AOF https://redis.io/topics/persistence#append-only-file
  appendonly yes
  # Disable RDB persistence, AOF persistence already enabled.
  save ""
## @param existingConfigmap The name of an existing ConfigMap with your custom configuration for Redis(R) nodes
##
existingConfigmap: ""

What is the expected behavior?

For chart version 23.1.1, the published Helm chart artifact should match the corresponding GitHub tag redis/23.1.1, or the project should document why published chart packages may differ from tagged source for the same chart version.

What do you see instead?

The GitHub tag redis/23.1.1 and the published Helm chart artifact for redis version 23.1.1 appear to contain different chart contents.

The GitHub tag points to Redis app version 8.2.1 and an AOF-only commonConfiguration. The published Helm chart repository artifact for the same chart version reports Redis app version 8.2.2, adds fips: "true" metadata, depends on common 2.32.3, and includes RedisSearch/ReJSON loadmodule lines in the default commonConfiguration.

This makes it difficult to audit or reproduce a chart-only upgrade from the GitHub tag, because helm dependency update consumes the published chart artifact rather than the tagged source tree.

Additional information

Operators commonly audit chart changes against GitHub tags before dependency upgrades. In this case, reviewing redis/23.1.1 in GitHub does not reveal the chart defaults that Helm actually installs from https://charts.bitnami.com/bitnami.

This can cause unexpected runtime behavior. For example, a chart-only upgrade intended to keep Redis runtime behavior unchanged may render Redis module load directives from the published artifact even though those directives are absent from the GitHub tag for the same chart version.

[carrodher]

Thanks for the detailed report and the thorough investigation.

This is expected behavior following the changes announced in #35164. To summarize what affects this repository:

• The source code in this repository is no longer automatically updated with new app versions or image rebuilds. The codebase is effectively frozen with respect to upstream application changes.
• The repository does still accept community contributions (bug fixes, chart improvements, etc.), but those contributions won't include app version bumps or new image tags coming from Bitnami's build pipeline.

The discrepancy you are seeing between the redis/23.1.1 Git tag and the published OCI artifact is because a small subset of Helm charts is actively maintained and updated as part of the Bitnami Secure Images offering. These charts are continuously rebuilt and verified against newer app versions and image tags. The OCI artifact at registry-1.docker.io/bitnamicharts/redis reflects this updated version, while the Git tag here corresponds to the point in time when the source was last committed to this repository.

[nicholasmhughes]

I don't read anything in the linked issue as "we're expecting our chart versions to be mutable, allowing us to willy-nilly change things surreptitiously whenever we feel like it".

Here's how I'm interpreting the flow given the current information:

1. Bitnami cut a 23.1.1 chart tag for Redis
2. That chart was published to the Helm repo with that tagged configuration
3. At some point, Bitnami updated the published Helm chart and overwrote the published Helm version
4. Bitnami thinks this mutable version behavior is okay

You're effectively allowing for configuration drift across deployments with the same version, which is generally not a great practice to adopt. If I deployed version 23.1.1 in August of last year and then deployed that same version again today, I'd expect the deployment to be identical. Isn't that the whole point of versioning?

I'm not saying that you can't have your whole separate "Secure Images" process and stop updating the "Legacy stuff", but I struggle to see how overwriting a version of the chart that should be considered "Legacy" with updated values is helping anyone. It's better practice to just cut a new chart version if you're updating the chart values, leaving the older tags as an accurate snapshot of that point in time.

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[nicholasmhughes]

I'd love activity. Bring on the activity.