Conversation
WalkthroughThe pull request updates the Helm chart for migrations by incrementing its version, removing the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Helm Chart
participant Kubernetes
User->>Helm Chart: Install/Upgrade migrations chart
Helm Chart->>Kubernetes: Deploy Job with job history limits
Kubernetes-->>Helm Chart: Retain N successful/failed Jobs (per limits)
Possibly related PRs
Suggested reviewers
Poem
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
charts/migrations/Chart.yaml(1 hunks)charts/migrations/README.md(2 hunks)charts/migrations/templates/job.yaml(1 hunks)charts/migrations/values.yaml(1 hunks)
🔇 Additional comments (4)
charts/migrations/values.yaml (1)
11-12: Introduced job history limit defaults
AddingsuccessfulJobsHistoryLimitandfailedJobsHistoryLimitwith sensible defaults (3 and 1) aligns the values schema with retention requirements.charts/migrations/Chart.yaml (1)
5-5: Bump chart version to 0.2.2
The version increment from0.2.1to0.2.2correctly reflects the addition of new history limit fields and removal ofttlSecondsAfterFinished.charts/migrations/README.md (2)
3-3: Update version badge to 0.2.2
The badge now matches the bumped chart version, keeping documentation in sync.
27-28: Document new job history limit keys
The table entries forjob.failedJobsHistoryLimit(default1) andjob.successfulJobsHistoryLimit(default3) accurately reflect the updated values schema.
| successfulJobsHistoryLimit: {{ .Values.job.successfulJobsHistoryLimit | default 3 }} | ||
| failedJobsHistoryLimit: {{ .Values.job.failedJobsHistoryLimit | default 1 }} |
There was a problem hiding this comment.
Invalid fields on Job spec: use TTLSecondsAfterFinished or CronJob
successfulJobsHistoryLimit and failedJobsHistoryLimit are CronJob retention settings, not Job spec fields. These will be rejected by the Kubernetes API. Either revert to ttlSecondsAfterFinished for Job cleanup or switch to a CronJob resource.
🤖 Prompt for AI Agents
In charts/migrations/templates/job.yaml at lines 11-12, the fields
successfulJobsHistoryLimit and failedJobsHistoryLimit are invalid for a Job spec
and cause Kubernetes API rejection. Replace these fields with
ttlSecondsAfterFinished to handle Job cleanup correctly, or change the resource
type to CronJob if you need to use those retention settings. Adjust the template
accordingly to use valid Job spec fields.
Summary by CodeRabbit