-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Labels
enhancementNew feature or requestNew feature or requestproviderRuntime provider implementationRuntime provider implementation
Description
Add Helm runtime provider to dtvem for managing Helm (Kubernetes package manager) versions.
Overview
Implement a Helm provider that allows users to install, manage, and switch between Helm versions using dtvem. DevOps teams managing Kubernetes clusters need to match Helm versions to Kubernetes server versions.
Why Helm Needs Version Management
- Kubernetes Compatibility: Different Helm versions support different Kubernetes versions
- Helm 3.0+ supports Kubernetes 1.16+
- Helm chart APIs changed significantly between major versions
- Multiple Clusters: Dev cluster (K8s 1.26/Helm 3.10) vs Prod cluster (K8s 1.28/Helm 3.13)
- Helm 2 vs Helm 3: Breaking changes between major versions
- Helm 2 used Tiller (server-side component)
- Helm 3 removed Tiller (client-only)
- Cannot use Helm 2 commands with Helm 3 charts
- Chart Compatibility: Some charts require specific Helm versions
- CI/CD Reproducibility: Must pin Helm version in deployment pipelines
Implementation Checklist
- Create
src/runtimes/helm/provider.go - Implement all 19
Providerinterface methods - Add
init()function for auto-registration:runtime.Register(NewProvider()) - Import in
src/main.go:_ "github.com/CodingWithCalvin/dtvem/src/runtimes/helm" - Update
schemas/runtimes.schema.jsonto add "helm" to runtime enum - Implement
Shims()method to return:["helm"] - Implement
ShouldReshimAfter()(likely false - plugin system separate) - Add detection logic for existing Helm installations (system, cloud CLIs)
- Implement download/installation logic from official sources
- Ensure cross-platform support (Windows, macOS, Linux)
- Add tests using provider contract harness (
internal/runtime/provider_test_harness.go) - Update documentation with Helm examples
Version Sources
- GitHub Releases: https://github.com/helm/helm/releases
- Official Get Script: https://get.helm.sh/
- Helm Releases: https://get.helm.sh/helm-v{version}-{os}-{arch}.tar.gz
Download Sources by Platform
- All Platforms: Helm provides prebuilt binaries in tar.gz/zip archives
- Format:
https://get.helm.sh/helm-v{version}-{os}-{arch}.tar.gz - Examples:
https://get.helm.sh/helm-v3.13.3-windows-amd64.ziphttps://get.helm.sh/helm-v3.13.3-darwin-arm64.tar.gzhttps://get.helm.sh/helm-v3.13.3-linux-amd64.tar.gz
- Format:
- Archive Structure: Binary is inside
{os}-{arch}/helmdirectory in archive - Checksums: SHA256 checksums available
Migration Sources
Detect and migrate from:
- System installations:
- Windows:
C:\Program Files\helm\, Chocolatey installations - macOS:
/usr/local/bin/helm, Homebrew installations - Linux:
/usr/bin/helm,/usr/local/bin/helm, snap installations
- Windows:
- Cloud Provider CLIs: Sometimes bundled with cloud tooling
Shims to Create
helm- Main Helm CLI (single executable)
Helm Plugins
Helm has a plugin system (helm plugin install):
- Plugins are installed to
~/.local/share/helm/plugins/or$HELM_PLUGINS - Plugin commands are like
helm <plugin-name> - Plugins are version-independent (mostly)
- Decision: Don't try to manage plugins, just core Helm binary
Automatic Reshim Detection
Implement ShouldReshimAfter():
- Returns
false- Helm plugins don't install separate executables - Plugin system is integrated into
helmcommand itself
Cross-Platform Considerations
- Single Binary: Helm is a single standalone binary
- Windows:
helm.exe - macOS/Linux:
helmbinary with execute permissions - No Dependencies: Completely standalone
- Architecture Support: amd64, arm64 (Apple Silicon), arm (Raspberry Pi)
Version Format
- Helm uses semantic versioning:
3.13.3,3.12.0,2.17.0 - Major versions: Helm 2 (legacy), Helm 3 (current)
- Format:
v{major}.{minor}.{patch}
Helm Version Compatibility Matrix
| Helm Version | Supported Kubernetes Versions |
|---|---|
| 3.13.x | 1.28.x - 1.25.x |
| 3.12.x | 1.27.x - 1.24.x |
| 3.11.x | 1.26.x - 1.23.x |
| 3.0.x - 3.10.x | 1.16+ (with version-specific ranges) |
| 2.x (EOL) | Pre-1.16 |
Testing Requirements
- Use provider contract harness in
runtimes/helm/provider_test.go - Test all 19 interface methods
- Test version detection from system installations
- Test installation on all platforms
- Test shim creation and execution
- Test archive extraction (helm binary is inside subdirectory)
Special Considerations
- Archive Extraction: Unlike single-file downloads, Helm binary is inside tar.gz
- Structure:
{os}-{arch}/helminside archive - Must extract and move binary to correct location
- Structure:
- Helm 2 EOL: Helm 2 is end-of-life (November 2020)
- Still may need to support for legacy clusters
- Warn users if installing Helm 2?
- Chart Repositories: Helm uses chart repos (not version-specific)
~/.config/helm/repositories.yaml- Shared across all Helm versions
- HELM_ Environment Variables*: Users may have custom HELM_HOME, HELM_CACHE_HOME
- Should these be version-specific? (Probably not)
Integration with Kubernetes Workflows
- Pair with kubectl: Often used together
- Consider documenting how to pin both versions
- Example:
.dtvem/runtimes.jsonwith both kubectl and helm
- Chart Versioning: Separate from Helm versioning
- Chart version in
Chart.yaml - Helm CLI version is what dtvem manages
- Chart version in
- CI/CD: Pin Helm version in deployment pipelines
- Ensures reproducible deployments
Helm Plugin Considerations
Popular Helm plugins users might have:
helm-diff: Show diff before upgradehelm-secrets: Manage secretshelm-push: Push charts to registries
These are installed via helm plugin install and go to plugin directory. dtvem doesn't need to manage them, but should ensure plugins continue working when switching Helm versions.
References
- Provider interface:
src/internal/runtime/provider.go - Example implementations:
src/runtimes/node/,src/runtimes/python/ - Adding providers guide:
.claude/CLAUDE.md - Helm releases: https://github.com/helm/helm/releases
- Helm documentation: https://helm.sh/docs/
- Version support: https://helm.sh/docs/topics/version_skew/
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or requestproviderRuntime provider implementationRuntime provider implementation