UP

upgrading-chart

Safely manages Helm chart dependency upgrades for PostgreSQL and Vault in the Chainloop ecosystem.

Install

mkdir -p .claude/skills/upgrading-chart && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/2467" && unzip -o skill.zip -d .claude/skills/upgrading-chart && rm skill.zip

Installs to .claude/skills/upgrading-chart

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Upgrades Helm chart dependencies (PostgreSQL, Vault) in the Chainloop project, including vendorized charts, container images, and CI/CD workflows. Use when the user mentions upgrading Helm charts, Bitnami dependencies, PostgreSQL chart, or Vault chart. CRITICAL - Major version upgrades are FORBIDDEN and must be escalated.
323 chars✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Intermediate

Key capabilities

  • Update container image versions for specific charts
  • Perform minor version upgrades for Bitnami charts
  • Validate version compatibility before applying changes
  • Lint and template Helm charts for verification
  • Rollback changes using Git and dependency cleanup

How it works

The process identifies the upgrade type, validates that the major version remains unchanged, updates the relevant Chart.yaml and workflow files, and verifies the result using linting and local deployment.

Inputs & outputs

You give it
Chart name and target version
You get back
Updated Chart.yaml and workflow files

When to use upgrading-chart

  • Upgrade Helm chart dependencies
  • Update container image version
  • Check for chart version updates
  • Validate PostgreSQL or Vault charts

About this skill

Upgrading Helm Chart Dependencies

This skill automates the upgrade process for Helm chart dependencies in the Chainloop project. Supports PostgreSQL and Vault (both Bitnami charts).

CRITICAL RESTRICTIONS

Version Upgrade Rules:

  • Patch upgrades (1.2.3 → 1.2.4): ALLOWED
  • Minor upgrades (1.2.x → 1.3.x): ALLOWED
  • Major upgrades (1.x.x → 2.x.x): FORBIDDEN - STOP IMMEDIATELY

MANDATORY: If major version upgrade is detected, STOP the process and inform the user that manual review is required.

Upgrade Types

The skill supports two upgrade types:

  1. Specific Image Upgrade: Update container image to specific version (chart unchanged)
  2. Chart Minor Version Upgrade: Update chart to latest minor version (may include image updates)

IMPORTANT: Container images are ONLY updated as part of chart upgrades, never independently (unless Type 1).

Process

1. Identify Upgrade Type

Ask the user which type of upgrade they want:

  • Type 1: Specific image version upgrade
  • Type 2: Latest minor chart version upgrade

Also ask which chart: postgresql or vault

2. Pre-Upgrade Validation

Check current state:

cat deployment/chainloop/charts/<chart-name>/Chart.yaml | grep "^version:"
cat deployment/chainloop/charts/<chart-name>/Chart.yaml | grep "^appVersion:"

3. Version Compatibility Check

For any version change, validate that major version remains the same:

CURRENT_MAJOR=$(echo "$CURRENT_VERSION" | cut -d. -f1)
TARGET_MAJOR=$(echo "$TARGET_VERSION" | cut -d. -f1)

if [ "$CURRENT_MAJOR" != "$TARGET_MAJOR" ]; then
    echo "FORBIDDEN: Major version upgrade detected"
    exit 1
fi

If major version upgrade detected, STOP and escalate.

Type 1: Specific Image Upgrade

See image-upgrade-process.md for detailed steps.

Summary:

  1. Locate target container image in Bitnami Containers
  2. Find commit with release message pattern
  3. Extract APP_VERSION from Dockerfile
  4. Update deployment/charts/<chart-name>/Chart.yaml appVersion
  5. Update .github/workflows/build_external_container_images.yaml commit hash

Type 2: Chart Minor Version Upgrade

See chart-upgrade-process.md for detailed steps.

Summary:

  1. Locate target chart version in Bitnami Charts CHANGELOG.md
  2. Validate minor version upgrade only
  3. Download and extract target chart
  4. Check for image changes (compare Chart.yaml)
  5. If images changed, update container image references
  6. Vendorize chart update (copy files)
  7. Update dependencies in correct order
  8. Update main chart dependency version
  9. Clean up temporary files

Verification

After any upgrade type, run:

# Lint charts
helm lint deployment/charts/<chart-name>
helm lint deployment/chainloop

# Template validation
helm template deployment/charts/<chart-name>
helm template deployment/chainloop

# Local testing
cd devel && docker compose up

# Verify image consistency
grep -r "appVersion\|image.*tag" deployment/charts/<chart-name>/

Files Modified

See files-modified.md for complete list.

Troubleshooting

Common issues:

  • Image Version Mismatch: Verify APP_VERSION matches Chart.yaml appVersion
  • Build Failures: Check commit reference in build workflow
  • Dependency Conflicts: Verify dependencies updated in correct order (vendorized first, then main chart)

Rollback

If issues occur:

git checkout HEAD -- deployment/
find deployment/ -name "Chart.lock" -delete
cd deployment/chainloop && helm dependency build
cd ../../devel && docker compose down && docker compose up

Important Notes

  • Dex is self-managed and follows a separate process (not covered by this skill)
  • Always use commit hashes for reproducibility
  • Dependencies must be updated in correct order: vendorized chart first, then main chart
  • Container images are found in Bitnami Containers repo, charts in Bitnami Charts repo

When not to use it

  • Major version upgrades
  • Self-managed Dex components

Prerequisites

HelmDockerGit

Limitations

  • Major version upgrades are forbidden
  • Container images are only updated as part of chart upgrades unless using Type 1

How it compares

This workflow enforces strict major version checks and specific dependency ordering compared to manual Helm updates.

Compared to similar skills

upgrading-chart side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
upgrading-chart (this skill)19moReviewIntermediate
deployment-engineer44moNo flagsAdvanced
k8s-rollouts16moNo flagsAdvanced
k8s-deploy16moReviewAdvanced

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

deployment-engineer

sickn33

Expert deployment engineer specializing in modern CI/CD pipelines, GitOps workflows, and advanced deployment automation. Masters GitHub Actions, ArgoCD/Flux, progressive delivery, container security, and platform engineering. Handles zero-downtime deployments, security scanning, and developer experience optimization. Use PROACTIVELY for CI/CD design, GitOps implementation, or deployment automation.

418

k8s-rollouts

rohitg00

Progressive delivery with Argo Rollouts and Flagger. Use when implementing canary deployments, blue-green deployments, or traffic shifting strategies.

15

k8s-deploy

rohitg00

Deploy and manage Kubernetes workloads with progressive delivery. Use for deployments, rollouts, blue-green, canary releases, scaling, and release management.

13

malsori-tekton-deployer

ancom21c

Submit Malsori releases to the live release broker API and wait for the broker to report terminal status. Use when the user wants to deploy the committed revision of this repository to the home k3s cluster through the standard shared-cluster release path.

00

linkerd-patterns

wshobson

Implement Linkerd service mesh patterns for lightweight, security-focused service mesh deployments. Use when setting up Linkerd, configuring traffic policies, or implementing zero-trust networking with minimal overhead.

672

deployment-pipeline-design

wshobson

Design multi-stage CI/CD pipelines with approval gates, security checks, and deployment orchestration. Use when architecting deployment workflows, setting up continuous delivery, or implementing GitOps practices.

670

Search skills

Search the agent skills registry