helmfile/examples
yxxhero 88a4c0928d feat: Add custom resource filtering options to kubedog tracker
Enhance kubedog tracker with flexible resource filtering options, allowing
users to control which resources are tracked.

Key Features:
- TrackKinds: Only track resources of specified types
- SkipKinds: Skip resources of specified types
- CustomTrackableKinds: Define custom resource types to actively track
- CustomStaticKinds: Define custom resource types that don't need tracking
- pkg/cluster/release.go: Manifest-based resource detection with filtering
- Comprehensive documentation and examples

Changes:
- pkg/kubedog/options.go: Add new tracking configuration fields and methods
- pkg/kubedog/tracker.go: Add filterResources and shouldSkipResource methods
- pkg/cluster/release.go: New package for manifest parsing and resource filtering
- docs/: Complete guides for custom tracking configuration
- examples/: Working examples demonstrating all filtering options

Benefits:
- Fine-grained control over resource tracking
- Support for custom resource types (CRDs)
- Performance improvement by skipping unnecessary tracking
- Backward compatible (defaults unchanged when not configured)

Signed-off-by: yxxhero <aiopsclub@163.com>
2026-01-25 18:49:15 +08:00
..
charts feat: add Helm 4 support while maintaining Helm 3 compatibility (#2262) 2025-11-19 07:49:30 +08:00
custom_tracking feat: Add custom resource filtering options to kubedog tracker 2026-01-25 18:49:15 +08:00
deployments update examples info (#658) 2023-01-26 07:34:43 +09:00
remote add example to demonstrate remote helmfiles & remote charts 2022-02-12 17:52:52 +09:00
resource_detection feat: Add custom resource filtering options to kubedog tracker 2026-01-25 18:49:15 +08:00
values Adding in examples for readme 2017-10-03 20:23:55 -05:00
README.md replace all mozilla/sops with getsops/sops (#1028) 2023-09-17 18:50:21 -05:00

README.md

Helmfile practical examples and advanced usages

Managing oneshot-jobs with Helmfile

In case you want to manage oneshot-jobs like a report generation or a database migration and so on, add a dedicated release spec for the job in helmfile.yaml like:

repositories:
  - name: yourorg
    url: https://yourorg.example.com/charts

releases:
  - name: dbmigrator
    labels:
      job: dbmigrator
    chart: ./dbmigrator
    # DB host, port, and connection opts for the environment
    values:
    - "deploy/environments/{{ env "RAILS_ENV" }}/values.yaml"
    # DB username and password encrypted with helm-secrets (getsops/sops)
    secrets:
    - "deploy/environments/{{ env "RAILS_ENV" }}/secrets.yaml"

You would then start a database migration job by executing:

# Start a database migration for the prod environment
$ RAILS_ENV=prod helmfile --selector job=dbmigrator sync

# Tail log until you are satisfied
$ kubectl logs -l job=dbmigrator

For more context, see this issue.