Skip to content

feat(runtime): add Helm provider #50

@CalvinAllen

Description

@CalvinAllen

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 Provider interface 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.json to 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

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.zip
      • https://get.helm.sh/helm-v3.13.3-darwin-arm64.tar.gz
      • https://get.helm.sh/helm-v3.13.3-linux-amd64.tar.gz
  • Archive Structure: Binary is inside {os}-{arch}/helm directory 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
  • 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 helm command itself

Cross-Platform Considerations

  • Single Binary: Helm is a single standalone binary
  • Windows: helm.exe
  • macOS/Linux: helm binary 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}/helm inside archive
    • Must extract and move binary to correct location
  • 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.json with both kubectl and helm
  • Chart Versioning: Separate from Helm versioning
    • Chart version in Chart.yaml
    • Helm CLI version is what dtvem manages
  • 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 upgrade
  • helm-secrets: Manage secrets
  • helm-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

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestproviderRuntime provider implementation

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions