update helm chart to release v2.5.13#1552
Conversation
WalkthroughThis PR bumps the Helm chart version from 2.5.7 to 2.5.13, updates the parseable container image tag to match, removes dependency declarations from the chart metadata, and adds the new chart version to the Helm index with updated timestamps. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@index.yaml`:
- Line 62: The index regeneration is overwriting historical `created` timestamps
because `helm repo index` is being run without merging; update the release
publishing step to run `helm repo index` only against the new chart file and
include the `--merge` flag with the existing index (e.g., `helm repo index
--merge previous_index.yaml .`) so older parseable entries retain their original
`created` values; locate the place that invokes `helm repo index` (the
publish/reindex routine) and change the invocation to pass the existing index
file path via `--merge` and target only the new release artifact.
| - apiVersion: v2 | ||
| appVersion: v2.5.7 | ||
| created: "2026-01-09T07:55:50.422041+05:30" | ||
| created: "2026-02-19T22:20:53.574503+05:30" |
There was a problem hiding this comment.
Historical created timestamps for all existing parseable entries were overwritten.
Every pre-existing parseable chart entry now shows a created timestamp of 2026-02-19, including charts originally published as far back as v0.0.1. The operator entries (which were not regenerated) still carry their original 2024-08-07 dates, confirming this is specific to the parseable index regeneration.
This is a known helm repo index behaviour: running helm repo index without --merge causes every existing entry to have its created value set to the current time, the same as the created timestamp of the new entry.
The recommended approach is to execute helm repo index on the new release file only, using --merge $previous_index.yaml; this adds the new release to the existing index while keeping the timestamps for older releases.
While Helm clients don't use created for install/upgrade decisions, the overwrite corrupts the historical audit trail and can confuse operators reviewing publication dates.
🔧 Recommended indexing workflow going forward
- helm repo index . --url https://charts.parseable.com/helm-releases/
+ # Package only the new chart into a temporary directory, then merge
+ mkdir -p /tmp/new-release
+ cp parseable-2.5.13.tgz /tmp/new-release/
+ helm repo index /tmp/new-release/ --url https://charts.parseable.com/helm-releases/ --merge index.yaml🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@index.yaml` at line 62, The index regeneration is overwriting historical
`created` timestamps because `helm repo index` is being run without merging;
update the release publishing step to run `helm repo index` only against the new
chart file and include the `--merge` flag with the existing index (e.g., `helm
repo index --merge previous_index.yaml .`) so older parseable entries retain
their original `created` values; locate the place that invokes `helm repo index`
(the publish/reindex routine) and change the invocation to pass the existing
index file path via `--merge` and target only the new release artifact.
|
Skipping tests because this is not a code change |
Summary by CodeRabbit
New Features
Chores