PLTF-2687: sync Chart.lock with current Chart.yaml dependencies#639
Conversation
Regenerates the lockfile via 'helm dependency update' to match the dependency declarations on main: - automation: 0.1.8 -> 0.1.9 (Chart.yaml has been at 0.1.9 since #634 etc.) - adds integrations-hub: 0.1.0 (declared in Chart.yaml in #614, never reflected in the lockfile) - digest + generated timestamp refreshed The lockfile had been drifting because earlier dependency-bump PRs only touched Chart.yaml. Same class of drift as #630. No functional behavior change in this PR — it brings the recorded lockfile into agreement with what helm dep update would produce anyway at build time. Laminar dependency unchanged at 0.1.11; the upgrade to 0.1.12 is tracked separately in #638.
|
@OpenHands look at failing validate chart versions PR check to bump the appropriate versions |
|
I'm on it! aivong-openhands can track my progress at all-hands.dev |
Co-authored-by: openhands <[email protected]>
all-hands-bot
left a comment
all-hands-bot
left a comment
There was a problem hiding this comment.
🟢 Good taste - Clean lockfile sync that resolves dependency drift.
[RISK ASSESSMENT]
- [Overall PR]
⚠️ Risk Assessment: 🟢 LOW
This is a routine Helm lockfile regeneration with no template or runtime changes. The lockfile now correctly reflects the declared Chart.yaml dependencies (automation 0.1.9 and integrations-hub 0.1.0). The drift sources are well-documented, and the chart version bump (0.7.17 → 0.7.18) follows proper conventions.
VERDICT:
✅ Worth merging: Necessary maintenance with no functional changes
KEY INSIGHT:
Lockfile-only changes like this should ideally be caught by CI to prevent drift accumulation across multiple PRs.
SummaryThe PR comment asked me to look at the failing What was done
Checklist
ConcisenessThe change is minimal — a single line edit in |
all-hands-bot
left a comment
all-hands-bot
left a comment
There was a problem hiding this comment.
🟢 Good taste - Clean lockfile sync resolving dependency drift.
[RISK ASSESSMENT]
- [Overall PR]
⚠️ Risk Assessment: 🟢 LOW
This is routine Helm lockfile maintenance. Chart.lock now correctly reflects Chart.yaml dependency versions (automation 0.1.9, integrations-hub 0.1.0 added). The chart version bump (0.7.17 → 0.7.18) follows semver conventions. No template or runtime behavior changes.
VERDICT:
✅ Worth merging: Necessary maintenance properly executed
KEY INSIGHT:
Lockfile drift resolved without introducing any functional changes - the lock now matches declared dependencies.
Ran helm dependency update after the Chart.yaml bump. With the lockfile in sync as of #639, the diff against main is now confined to the laminar entry plus the digest/timestamp refresh.
* PLTF-XXXX: bump laminar chart 0.1.11 -> 0.1.12 and openhands 0.7.18 -> 0.7.19 Pulls in laminar 0.1.12 changes from upstream: - lmnr-ai/lmnr-helm#27 unifies LLM provider env vars (LLM_PROVIDER, LLM_API_KEY, LLM_BASE_URL, LLM_MODEL_SMALL|MEDIUM|LARGE) across frontend, app-server, and app-server-consumer; renames the legacy GOOGLE_GENERATIVE_AI_API_KEY secret to LLM_API_KEY; switches image names from app-server/frontend/query-engine to the -ee suffixed variants; defaults SIGNALS_ENABLED=true on the frontend. - lmnr-ai/lmnr-helm#28 is docs-only. Draft PR for testing in a Replicated environment first to validate the upgrade applies cleanly without StatefulSet immutability errors, the class of failure that surfaced when upgrading 0.1.9 -> 0.1.11 in #625 (volumeClaimTemplates change on laminar-rabbitmq). For this 0.1.11 -> 0.1.12 hop, diffing the chart templates shows the structural StatefulSet changes (volumeClaimTemplates added in 0.1.10, checksum/config annotations added in 0.1.11) have already been absorbed by the prior upgrade. Only three Deployments change in 0.1.12: app-server, app-server-consumer, frontend (LLM env var rename + image swap). So in theory no orphan-delete recipe is required; this PR validates that empirically against a Replicated install. * PLTF-XXXX: regenerate Chart.lock for laminar 0.1.12 bump Ran helm dependency update after the Chart.yaml bump. With the lockfile in sync as of #639, the diff against main is now confined to the laminar entry plus the digest/timestamp refresh.
3 participants
Summary
Syncs
charts/openhands/Chart.lockwith the dependency declarations currently incharts/openhands/Chart.yaml. Lockfile had been drifting because the recent dependency bumps in #614, #631, and #632 only touchedChart.yaml. Same class of drift fixed previously in #630.Regenerated by running
helm dependency updateagainstcharts/openhandson main.Diff vs current Chart.lock on main
Drift sources, in order:
automationwas bumped from0.1.7→0.1.8in #631 (PLTF-2506 Release 1.29.1) and again from0.1.8→0.1.9in #632 (PLTF-2507 external Postgres bootstrap). Lockfile was stale at0.1.8.integrations-hubwas added to Chart.yaml in #614 at0.1.0but never landed in the lockfile.0.1.11. The upgrade to0.1.12is tracked separately in #638.Why this is its own PR
Keeps the lock-sync diff minimal and reviewable in isolation from the in-flight laminar 0.1.12 upgrade. The 0.1.12 PR can rebase on top of this when it's ready to come out of draft, picking up a clean Chart.lock that only needs the laminar version line touched.
Risk
Minimal. The lockfile records resolved dependency versions; values weren't already aligned with the declared Chart.yaml, so at runtime
helm dep update(or the equivalent build-time step) would produce the same resolution anyway. No template, service, or behavior changes.Manual intervention
None required.