`docs/index.yaml`: every `created` timestamp is rewritten to the index-build time on each release (breaks release-age tooling, e.g. Renovate `minimumReleaseAge`)

[YAMASHITAHiroki]

Summary

Every entry in https://kedacore.github.io/charts/index.yaml has its created field set to the moment the index was last regenerated, not the real release time of each chart version. As a result, the created value is the same timestamp (down to the second) for all versions of all charts (keda, keda-add-ons-http, external-scaler-azure-cosmos-db).

Evidence

All entries currently share the same second (…T16:25:00), differing only in the sub-second fraction:

$ curl -s https://kedacore.github.io/charts/index.yaml | grep -E 'name:|version:|created:'
...
    created: "2026-06-08T16:25:00.550388659Z"   # keda 2.20.1
    created: "2026-06-08T16:25:00.494452006Z"   # keda 2.16.1 (released months ago, same stamp)
    created: "2026-06-08T16:25:00.084623717Z"   # external-scaler-azure-cosmos-db 0.1.0

The real release dates are weeks/months apart, e.g. (from GitHub Releases): v2.20.0 2026-06-02, v2.19.0 2026-02-02.

Root cause

CONTRIBUTING.md → Shipping a new version → step 6 runs:

helm repo index docs --url https://kedacore.github.io/charts

This re-indexes the entire docs/ directory, which rebuilds the index from scratch and stamps created: <now> on every .tgz it finds, discarding the previously published timestamps.

Impact

created no longer reflects when each version was published — it reflects the last time the index was rebuilt. So every version except the most recent carries a created that is too recent (often by months), and even the most recent version's created is reset again whenever any chart in the repo is published, since step 6 re-indexes all of docs/ (e.g. a keda-add-ons-http release resets the created of every keda version too, although keda itself didn't change).

This breaks consumers that treat created as a release timestamp — most commonly release-age / stability gating such as Renovate's minimumReleaseAge ("wait N days after a release before proposing an update"). The age is measured from the wrong epoch (the last index rebuild, not the real release), so the soak window is unreliable. Two consequences in particular:

• Cross-chart coupling: because one rebuild restamps every chart at once, a release of any chart in the repo restarts the N-day window for all charts — keda updates can be delayed by an unrelated keda-add-ons-http release.
• Already-aged versions get re-blocked: a version that had already cleared the N-day window has its created reset to "now", so its age drops back to zero and it is held for another N days before a PR can be created.

Desired outcome

Ideally, each version's created would reflect its actual publish time and stay stable across subsequent index rebuilds, so that release-age / stability tooling can rely on it.

[linkvt]

Good finding, I'll have a look at that and try to fix things retroactively as well.