helm repo index changing created timestamp

[puckpuck]

Output of helm version: version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}

When I do a helm repo index . it will redo all entries in my index.yaml file (including existing ones) updating the timestamp of the files.

This is an issue because of the recommended build process for using Github pages to host a repo.
When I do a github checkout gh-pages my existing chart package binaries and index.yaml file will get a new timestamp. So when you do a helm repo index attempting to include a new version of your chart, the created property for each prior chart also gets updated with the new timestamps.

Should helm repo index . not update the created timestamp if no other properties for existing charts have changed or do we need a new command line option to force this behavior?

[puckpuck]

There is an "ugly" workaround:

1. put your new chart in its own folder
2. helm repo index --merge <path/to/existing/index.yaml> .
3. mv index.yaml <path/to/existing/index.yaml
4. mv <my-new-chart.tgz> <original/path>
5. git commit

Hoping there is a cleaner way to do this.

[bacongobbler]

At first glance, this seems intentional. helm repo index generates a new index at the time it is invoked, so it isn't surprising that the created timestamp is being updated.

helm repo index --merge's use case is to merge an existing index into a new one, only modifying what was changed. The stable repository uses the latter to maintain their index. I'd suggest looking at their repo-sync.sh script for ideas.

Let us know how you get along.

[puckpuck]

I agree that the linked script replicates what my workaround described above.

However, the digest to the previous chart versions doesn't change. Shouldn't updates to existing chart definitions be predicated on a change to the digest as well?

[jgustie]

I was also expecting the behavior where existing entries had the created timestamp preserved while the .generated timestamp and the created timestamps of any new entries would be reflect the current time.

In our case we maintain a simple Helm repository on the file system and just re-run helm repo index . after dropping a new chart into the directory. We can use the workaround here, but it would be nice if existing entries (matched by digest) weren't updated.

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[bacongobbler]

closing as stale.