You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During 2.7.0 release, we were affected by a bug that causes an issue to update the Helm repo index.
TL;DR when releasing two different charts in a small time interval, the release of second chart overrides the recent index update made for the release of the first chart.
After identifying the issue, we ran again the release for Helm chart eck-operator-2.7.0. This created a new eck-operator-2.7.0.tgz with a different sha256, but it didn't upload it because the helm release tool currently doesn't allow to upload an existed file (code) and eventually updated the index with the new sha256.
Hence the question: why do have different sha256 when creating eck-operator-2.7.0.tgz from the same source files?
I think this is actually due to gzip and is intentional by design. Part of the gzip header has a mod time for whatever is compressed in the file, so by calling helm package multiple times, each one creates their own tarball which is then packaged by gzip and given a unique shasum because the modtime differed.
source: helm/helm#3612 (comment)
From that, we have two problems:
when we publish an Helm chart in x.y.z-snapshot, we never override the .tgz, only the index
if we re-publish an Helm chart in x.y.z (event that should not happen), we don't override the .tgz, only the index
Proposed changes for the Helm release tool:
allow to override the .tgz for snapshots releases (dev Helm repo)
not allow to override the .tgz for tagged releases but also not allow to update the index (prod Helm repo)
During the 2.7.0 release, we should have removed eck-operator-2.7.0.tgz before running the tool again to update the index correctly to avoid this sha256 mismatch.
Reported in the Elastic Stack Community Slack:
The text was updated successfully, but these errors were encountered: