Coder Legion - Recent posts tagged chart

Helm Chart Testing in Production: Layers, Tools, and a Minimum CI Pipeline

Sat, 14 Feb 2026 09:43:36 +0000

When a Helm chart fails in production, the impact is immediate and visible. A misconfigured ServiceAccount, a typo in a ConfigMap key, or an untested conditional in templates can trigger incidents that cascade through your entire deployment pipeline. The irony is that most teams invest heavily in testing application code while treating Helm charts as “just configuration.”

Chart testing is fundamental for production-quality Helm deployments. For comprehensive coverage of testing along with all other Helm best practices, visit our complete Helm guide.

Helm charts are infrastructure code. They define how your applications run, scale, and integrate with the cluster. Treating them with less rigor than your application logic is a risk most production environments cannot afford.

The Real Cost of Untested Charts

In late 2024, a medium-sized SaaS company experienced a 4-hour outage because a chart update introduced a breaking change in RBAC permissions. The chart had been tested locally with helm install --dry-run, but the dry-run validation doesn’t interact with the API server’s RBAC layer. The deployment succeeded syntactically but failed operationally.

The incident revealed three gaps in their workflow:

No schema validation against the target Kubernetes version
No integration tests in a live cluster
No policy enforcement for security baselines

These gaps are common. According to a 2024 CNCF survey on GitOps practices, fewer than 40% of organizations systematically test Helm charts before production deployment.

The problem is not a lack of tools—it’s understanding which layer each tool addresses.

Testing Layers: What Each Level Validates

Helm chart testing is not a single operation. It requires validation at multiple layers, each catching different classes of errors.

Layer 1: Syntax and Structure Validation

What it catches: Malformed YAML, invalid chart structure, missing required fields

Tools:

helm lint: Built-in, minimal validation following Helm best practices
yamllint: Strict YAML formatting rules

Example failure caught:

# Invalid indentation breaks the chart
resources:
  limits:
      cpu: "500m"
    memory: "512Mi"  # Incorrect indentation

Limitation: Does not validate whether the rendered manifests are valid Kubernetes objects.

Layer 2: Schema Validation

What it catches: Manifests that would be rejected by the Kubernetes API

Primary tool: kubeconform

Kubeconform is the actively maintained successor to the deprecated kubeval. It validates against OpenAPI schemas for specific Kubernetes versions and can include custom CRDs.

Project Profile:

Maintenance: Active, community-driven
Strengths: CRD support, multi-version validation, fast execution
Why it matters: helm lint validates chart structure, but not if rendered manifests match Kubernetes schemas

Example failure caught:

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: nginx:latest
# Missing required field: spec.selector

Configuration example:

helm template my-chart . | kubeconform \
  -kubernetes-version 1.30.0 \
  -schema-location default \
  -schema-location 'https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json' \
  -summary

Example CI integration:

#!/bin/bash
set -e

KUBE_VERSION="1.30.0"

echo "Rendering chart..."
helm template my-release ./charts/my-chart > manifests.yaml

echo "Validating against Kubernetes $KUBE_VERSION..."
kubeconform \
  -kubernetes-version "$KUBE_VERSION" \
  -schema-location default \
  -summary \
  -output json \
  manifests.yaml | jq -e '.summary.invalid == 0'

Alternative: kubectl --dry-run=server (requires cluster access, validates against actual API server)

Layer 3: Unit Testing

What it catches: Logic errors in templates, incorrect conditionals, wrong value interpolation

Unit tests validate that given a set of input values, the chart produces the expected manifests. This is where template logic is verified before reaching a cluster.

Primary tool: helm-unittest

helm-unittest is the most widely adopted unit testing framework for Helm charts.

Project Profile:

GitHub: 3.3k+ stars, ~100 contributors
Maintenance: Active (releases every 2-3 months)
Primary maintainer: Quentin Machu (originally @QubitProducts, now independent)
Commercial backing: None
Bus Factor: Medium-High (no institutional backing, but consistent community engagement)

Strengths:

Fast execution (no cluster required)
Familiar test syntax (similar to Jest/Mocha)
Snapshot testing support
Good documentation

Limitations:

Doesn’t validate runtime behavior
Cannot test interactions with admission controllers
No validation against actual Kubernetes API

Example test scenario:

# tests/deployment_test.yaml
suite: test deployment
templates:
  - deployment.yaml
tests:
  - it: should set resource limits when provided
    set:
      resources.limits.cpu: "1000m"
      resources.limits.memory: "1Gi"
    asserts:
      - equal:
          path: spec.template.spec.containers[0].resources.limits.cpu
          value: "1000m"
      - equal:
          path: spec.template.spec.containers[0].resources.limits.memory
          value: "1Gi"

  - it: should not create HPA when autoscaling disabled
    set:
      autoscaling.enabled: false
    template: hpa.yaml
    asserts:
      - hasDocuments:
          count: 0

Alternative: Terratest (Helm module)

Terratest is a Go-based testing framework from Gruntwork that includes first-class Helm support. Unlike helm-unittest, Terratest deploys charts to real clusters and allows programmatic assertions in Go.

Example Terratest test:

func TestHelmChartDeployment(t *testing.T) {
    kubectlOptions := k8s.NewKubectlOptions("", "", "default")
    options := &helm.Options{
        KubectlOptions: kubectlOptions,
        SetValues: map[string]string{
            "replicaCount": "3",
        },
    }
    
    defer helm.Delete(t, options, "my-release", true)
    helm.Install(t, options, "../charts/my-chart", "my-release")
    
    k8s.WaitUntilNumPodsCreated(t, kubectlOptions, metav1.ListOptions{
        LabelSelector: "app=my-app",
    }, 3, 30, 10*time.Second)
}

When to use Terratest vs helm-unittest:

Use helm-unittest for fast, template-focused validation in CI
Use Terratest when you need full integration testing with Go flexibility

Layer 4: Integration Testing

What it catches: Runtime failures, resource conflicts, actual Kubernetes behavior

Integration tests deploy the chart to a real (or ephemeral) cluster and verify it works end-to-end.

Primary tool: chart-testing (ct)

chart-testing is the official Helm project for testing charts in live clusters.

Project Profile:

Ownership: Official Helm project (CNCF)
Maintainers: Helm team (contributors from Microsoft, IBM, Google)
Governance: CNCF-backed with public roadmap
LTS: Aligned with Helm release cycle
Bus Factor: Low (institutional backing from CNCF provides strong long-term guarantees)

Strengths:

De facto standard for public Helm charts
Built-in upgrade testing (validates migrations)
Detects which charts changed in a PR (efficient for monorepos)
Integration with GitHub Actions via official action

Limitations:

Requires a live Kubernetes cluster
Initial setup more complex than unit testing
Does not include security scanning

What ct validates:

Chart installs successfully
Upgrades work without breaking state
Linting passes
Version constraints are respected

Example ct configuration:

# ct.yaml
target-branch: main
chart-dirs:
  - charts
chart-repos:
  - bitnami=https://charts.bitnami.com/bitnami
helm-extra-args: --timeout 600s
check-version-increment: true

Typical GitHub Actions workflow:

name: Lint and Test Charts

on: pull_request

jobs:
  lint-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Set up Helm
        uses: azure/setup-helm@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Set up chart-testing
        uses: helm/chart-testing-action@v2

      - name: Run chart-testing (lint)
        run: ct lint --config ct.yaml

      - name: Create kind cluster
        uses: helm/kind-action@v1

      - name: Run chart-testing (install)
        run: ct install --config ct.yaml

When ct is essential:

Public chart repositories (expected by community)
Charts with complex upgrade paths
Multi-chart repositories with CI optimization needs

Layer 5: Security and Policy Validation

What it catches: Security misconfigurations, policy violations, compliance issues

This layer prevents deploying charts that pass functional tests but violate organizational security baselines or contain vulnerabilities.

Policy Enforcement: Conftest (Open Policy Agent)

Conftest is the CLI interface to Open Policy Agent for policy-as-code validation.

Project Profile:

Parent: Open Policy Agent (CNCF Graduated Project)
Governance: Strong CNCF backing, multi-vendor support
Production adoption: Netflix, Pinterest, Goldman Sachs
Bus Factor: Low (graduated CNCF project with multi-vendor backing)

Strengths:

Policies written in Rego (reusable, composable)
Works with any YAML/JSON input (not Helm-specific)
Can enforce organizational standards programmatically
Integration with admission controllers (Gatekeeper)

Limitations:

Rego has a learning curve
Does not replace functional testing

Example Conftest policy:

# policy/security.rego
package main

import future.keywords.contains
import future.keywords.if
import future.keywords.in

deny[msg] {
  input.kind == "Deployment"
  container := input.spec.template.spec.containers[_]
  not container.resources.limits.memory
  msg := sprintf("Container '%s' must define memory limits", [container.name])
}

deny[msg] {
  input.kind == "Deployment"
  container := input.spec.template.spec.containers[_]
  not container.resources.limits.cpu
  msg := sprintf("Container '%s' must define CPU limits", [container.name])
}

Running the validation:

helm template my-chart . | conftest test -p policy/ -

Alternative: Kyverno

Kyverno offers policy enforcement using native Kubernetes manifests instead of Rego. Policies are written in YAML and can validate, mutate, or generate resources.

Example Kyverno policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-container-limits
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "All containers must have CPU and memory limits"
      pattern:
        spec:
          containers:
          - resources:
              limits:
                memory: "?*"
                cpu: "?*"

Conftest vs Kyverno:

Conftest: Policies run in CI, flexible for any YAML
Kyverno: Runtime enforcement in-cluster, Kubernetes-native

Both can coexist: Conftest in CI for early feedback, Kyverno in cluster for runtime enforcement.

Vulnerability Scanning: Trivy

Trivy by Aqua Security provides comprehensive security scanning for Helm charts.

Project Profile:

Maintainer: Aqua Security (commercial backing with open-source core)
Scope: Vulnerability scanning + misconfiguration detection
Helm integration: Official trivy helm command
Bus Factor: Low (commercial backing + strong open-source adoption)

What Trivy scans in Helm charts:

Vulnerabilities in referenced container images
Misconfigurations (similar to Conftest but pre-built rules)
Secrets accidentally committed in templates

Example scan:

trivy helm ./charts/my-chart --severity HIGH,CRITICAL --exit-code 1

Sample output:

myapp/templates/deployment.yaml (helm)
====================================

Tests: 12 (SUCCESSES: 10, FAILURES: 2)
Failures: 2 (HIGH: 1, CRITICAL: 1)

HIGH: Container 'app' of Deployment 'myapp' should set 'securityContext.runAsNonRoot' to true
════════════════════════════════════════════════════════════════════════════════════════════════
Ensure containers run as non-root users

See https://kubernetes.io/docs/concepts/security/pod-security-standards/
────────────────────────────────────────────────────────────────────────────────────────────────
 myapp/templates/deployment.yaml:42

Commercial support:
Aqua Security offers Trivy Enterprise with advanced features (centralized scanning, compliance reporting). For most teams, the open-source version is sufficient.

Other Security Tools

Polaris (Fairwinds)

Polaris scores charts based on security and reliability best practices. Unlike enforcement tools, it provides a health score and actionable recommendations.

Use case: Dashboard for chart quality across a platform

Checkov (Bridgecrew/Palo Alto)

Similar to Trivy but with a broader IaC focus (Terraform, CloudFormation, Kubernetes, Helm). Pre-built policies for compliance frameworks (CIS, PCI-DSS).

When to use Checkov:

Multi-IaC environment (not just Helm)
Compliance-driven validation requirements

Enterprise Selection Criteria

Bus Factor and Long-Term Viab

Project Weather (Extras): Beyond AI - Building a Robust, User-Centric Dashboard

Fri, 23 Jan 2026 07:06:46 +0000

In previous posts, we explored the core of the Project Weather, focusing on its basic backend-frontend platform and its AI prediction capabilities. Once these points were achieved and the application was operational, certain improvement aspects arose concerning a more fluid and intuitive frontend experience.

This post unveils the "extras"—the significant enhancements and design decisions that transformed Project Weather from a basic pilot into a comprehensive, production-ready weather dashboard. These improvements, although not directly related to AI prediction, were crucial for building a reliable, scalable, and delightful user experience.

1. Expanding Metrics and Data Collection: From Basic to Comprehensive

Our initial weather dashboard, while functional, only provided basic metrics like temperature, wind, and humidity. To evolve into a truly useful weather station, we needed more data. This required significant modifications in both our backend data collection script and the frontend visualization.

New Metrics & Dynamic Visualizations

We revamped our Python read_weather.py script to fetch and store four new critical weather variables:

Cloudiness (%): Percentage of sky covered.
Visibility (km): Distance of vision (crucial for fog or haze conditions).
Rain (mm): Rainfall in the last hour.
Snow (mm): Snowfall in the last hour.

In the frontend, effectively visualizing these diverse data types was key. We implemented conditional logic within Chart.js to adapt the chart type based on the data:

Line charts for continuous variables like temperature and wind speed.
Area (filled) charts for humidity and cloudiness, providing a sense of accumulation or coverage.
Bar charts for precipitation (rain/snow), as bars visually represent accumulated amounts more intuitively.

Automatic Data Migration

A common challenge when adding new data fields to an existing system is managing historical data. We designed a robust backend system to automatically detect and migrate older CSV files (with 11 columns) to the new 15-column format. Crucially, this system elegantly handled the missing values for the new metrics, filling them with sensible default values (e.g., 0 for rain/snow), thus preventing any loss of historical context and ensuring data integrity across the entire dataset. This automated process was vital for a smooth, fluid transition without requiring manual intervention.

2. Comprehensive Internationalization (i18n) System: A Truly Global Application

To make the Project Weather accessible to a wider audience, a complete internationalization (i18n) system was a top priority. We transformed the web application into a fully bilingual platform (Spanish/English) with dynamic language switching, without the need for page reloads.

Translation Architecture

We built a centralized const translations dictionary in JavaScript, containing all text strings used in the application. This approach ensured consistency and simplified maintenance.

Static Texts: HTML elements requiring translation were tagged with a data-i18n-key attribute. A JavaScript function then automatically iterated through these elements, replacing their content with the corresponding translation from the active dictionary.
Dynamic Texts: Crucially, all JavaScript logic responsible for generating dynamic strings (e.g., "Feels like," "Wind speed," KPI labels, and chart tooltips) was refactored to read directly from the currently selected language dictionary. This ensured that every piece of text, regardless of whether it was static HTML or dynamically generated, was correctly localized.

Date and Number Formatting

Beyond text, cultural formatting for dates and numbers is essential. We leveraged Intl.DateTimeFormat and integrated it with Chart.js to ensure that dates on chart axes and in data cards were displayed in the culturally correct format (e.g., "10 nov" vs. "Nov 10"). Number formats (e.g., decimal separators) were also adapted accordingly.

Persistence

To enhance user experience, the language preference is stored in localStorage, so the application remembers the user's chosen language across visits.

3. Advanced Interactivity: Custom Time Range Filtering

Empowering users with precise data exploration capabilities was a key objective. We significantly improved the dashboard's interactivity by introducing advanced time range filtering.

Custom Range Selector

Alongside the predefined ranges (1H, 1D, 1W, 1M, 1Y, All), we added a "Custom" option. Activating this option dynamically reveals two date input fields (start-date and end-date).

Dynamic Filtering Logic

The core rendering engine for our charts was modified to accept arbitrary start and end dates. This allows users to define any time window. Upon selection, the system recalculates all statistics (maximums, minimums, and averages) and re-renders the graphs based exclusively on the user-defined period. This granular control dramatically improves the analytical utility of the dashboard.

4. UI/UX Enhancements: Polishing the User Experience

The final touches on UI/UX consisted of refining the aesthetics and usability, transforming a functional dashboard into a polished and engaging application.

Dynamic Weather Icons

We developed a smart getWeatherIcon logic that analyzes the weather description returned by the API (e.g., "scattered clouds," "drizzle") and the cloudiness percentage. This function dynamically displays the most representative icon from Feather Icons (sun, cloud, rain, snow, fog) alongside the city name and current weather condition, providing immediate visual cues about the weather.

Professional Corporate Header

The simple page title was replaced by a professional-grade <header> that integrates:

The Datalaria logo.
A dynamic "How it was made" link that intelligently switches the URL to the English or Spanish version of this blog post, depending on the application's current language setting.
Grouped configuration controls for language selection and dark mode toggle, providing a clean and organized interface for user preferences.

Loading Feedback

Addressing visual bugs and improving user feedback during asynchronous data processing was critical. We implemented a subtle loading spinner and clear status messages that appear while data is being fetched and rendered. This prevents users from seeing blank or partially loaded charts and assures them that the application is actively processing their requests.

Conclusion: A Holistic Approach to Application Development

While the AI prediction model is a testament to the power of machine learning, these "extra" features are evidence of the comprehensive development approach adopted with the Project Weather. They demonstrate that building a truly valuable application goes beyond its core functionality, encompassing:

Robust Data Engineering: Ensuring data quality and smooth migration.
Global Accessibility: Through thoughtful internationalization.
User Empowerment: Via advanced filtering options.
Refined User Experience: With intuitive visuals and clear feedback.

The result is a weather dashboard with a degree of intelligence, intuitive, and easy to use, in which backend logic and careful frontend design converge.

Finally, these improvements represent the closing of the first operational version of the project, and from which, in the medium term, we will incorporate new enhancements and changes as they are required and allow us to improve the user experience and experiment with new features and characteristics.