Description
When upgrading a Helm release via Helmsman by bumping only the chart version: in the DSF (without explicitly setting image.tag via set:), the pod continues running the old Docker image even though the new chart version has a different default image.tag in its values.yaml.
Steps to Reproduce
- Deploy a release with chart version
1.3.0 (e.g. datashare) — no explicit image.tag in DSF set: block
- Confirm the chart's published
values.yaml default for image.tag is 1.3.0
- Bump the chart
version: in the DSF to 1.3.0-beta.1
- Verify the new chart's default image tag:
helm show values mosip/datashare --version 1.3.0-beta.1 | grep tag
# tag: 1.3.0-beta.1
- Run Helmsman — release upgrades successfully (new REVISION created)
- Check the running pod image — still
1.3.0, not 1.3.0-beta.1
Expected Behaviour
When no image.tag is explicitly set in the DSF, bumping the chart version should result in Helm using the new chart's values.yaml defaults, including the updated image.tag.
Actual Behaviour
The old image.tag from the previous release is retained. Helm upgrade is behaving as if --reuse-values is active, carrying forward the previously stored values instead of using the new chart defaults.
Confirmed via:
helm get values datashare -n datashare
# returns: image.tag: 1.3.0 ← old value retained
Environment
- Tool: Helmsman
- Chart:
mosip/datashare
- Chart versions tested:
1.3.0 → 1.3.0-beta.1
- DSF entry (no valuesFile, no set: image.tag):
datashare:
namespace: datashare
enabled: true
version: 1.3.0-beta.1
chart: mosip/datashare
priority: -10
timeout: 1200
Workaround
Explicitly pin image.tag in the DSF set: block:
set:
image.tag: "1.3.0-beta.1"
This overrides --reuse-values behaviour since --set flags always take final precedence.
Questions / Request
- Is Helmsman passing
--reuse-values by default during helm upgrade? If so, is there a DSF-level option (e.g. resetValues: true or helmFlags: ["--reset-values"]) to disable this per-release without requiring explicit image.tag pins?
- Should Helmsman document this behaviour clearly so operators know to always pin
image.tag when bumping chart versions?
Description
When upgrading a Helm release via Helmsman by bumping only the chart
version:in the DSF (without explicitly settingimage.tagviaset:), the pod continues running the old Docker image even though the new chart version has a different defaultimage.tagin itsvalues.yaml.Steps to Reproduce
1.3.0(e.g.datashare) — no explicitimage.tagin DSFset:blockvalues.yamldefault forimage.tagis1.3.0version:in the DSF to1.3.0-beta.11.3.0, not1.3.0-beta.1Expected Behaviour
When no
image.tagis explicitly set in the DSF, bumping the chart version should result in Helm using the new chart'svalues.yamldefaults, including the updatedimage.tag.Actual Behaviour
The old
image.tagfrom the previous release is retained. Helm upgrade is behaving as if--reuse-valuesis active, carrying forward the previously stored values instead of using the new chart defaults.Confirmed via:
helm get values datashare -n datashare # returns: image.tag: 1.3.0 ← old value retainedEnvironment
mosip/datashare1.3.0→1.3.0-beta.1Workaround
Explicitly pin
image.tagin the DSFset:block:This overrides
--reuse-valuesbehaviour since--setflags always take final precedence.Questions / Request
--reuse-valuesby default duringhelm upgrade? If so, is there a DSF-level option (e.g.resetValues: trueorhelmFlags: ["--reset-values"]) to disable this per-release without requiring explicitimage.tagpins?image.tagwhen bumping chart versions?