Release Process - cturner8/kube-mcp GitHub Wiki

This guide covers how to create releases for both the container image and Helm chart.

Overview

The project uses GitHub Actions to automate releases:

  • Container images: Tagged with v* (e.g., v0.0.1) and published to ghcr.io/cturner8/kube-mcp
  • Helm charts: Tagged with chart-v* (e.g., chart-v0.0.1) and published to ghcr.io/cturner8

Pre-release checklist

Before creating any release, ensure the following conditions are met to prevent common mistakes:

  • You are on the main branch

    git branch --show-current  # Should output: main

  • Local main branch is up to date with the remote

    git fetch origin
git log --oneline main..origin/main  # Should show no output if up to date

  • All changes are merged to main

    • Verify all required pull requests have been merged
    • Check that the latest commits in main are visible in GitHub
    • Run: git log main --oneline -5 to verify recent commits

  • Working directory is clean (no uncommitted changes)

    git status  # Should show: nothing to commit, working tree clean

  • charts/kube-mcp/Chart.yaml versions are correct

    • version field matches your intended Helm chart release (e.g., 0.0.2)
    • appVersion field matches your intended application/container image version (e.g., 0.0.2)
    • Both values follow semantic versioning (semver) format
    • Run: cat charts/kube-mcp/Chart.yaml | grep -E "^(version|appVersion)"

Release Checklist

Before pushing a release tag, verify:

  • charts/kube-mcp/Chart.yaml has correct version and appVersion
  • You're on the correct branch (typically main)

Version Numbering Guidelines

Follow semantic versioning (semver):

  • Major (x.0.0): Breaking changes to API, tools, or chart structure
  • Minor (0.x.0): New features, new tools, backward-compatible changes
  • Patch (0.0.x): Bug fixes, documentation updates

Version Management in Chart.yaml

Before creating a release, you must update the version numbers in charts/kube-mcp/Chart.yaml:

apiVersion: v2
name: kube-mcp-chart
description: A Helm chart for kube-mcp
type: application
version: 0.0.1              # Helm chart version - update this
# renovate: image=ghcr.io/cturner8/kube-mcp
appVersion: "0.0.1"         # Application version - update this

Version Fields

  • version: The Helm chart version (semver format). Increment this for any changes to the chart itself (templates, values, etc.)
  • appVersion: The version of the kube-mcp application. Should match the container image tag you're releasing

Renovate Integration

The # renovate: comment enables automatic updates of appVersion when new container images are published. However, you must manually update these versions when creating releases.

Creating a Container Image Release

  1. Update Chart.yaml:

    cd charts/kube-mcp
# Edit Chart.yaml and update appVersion to your new version
# Example: appVersion: "0.0.2"

  2. Commit and push:

    git add charts/kube-mcp/Chart.yaml
git commit -m "Bump chart app version to 0.0.2"
git push origin main

  3. Create and push the tag:

    git tag v0.0.2
git push origin v0.0.2

  4. The .github/workflows/build.yml workflow will:

    • Build the container image
    • Push to ghcr.io/cturner8/kube-mcp:0.0.2
    • Create a draft GitHub release with auto-generated notes

  5. Review the generated release notes.

  6. Publish the release once ready.

The automated release is created in draft status to allow for review of generated release notes or to make any manual revisions.

Creating a Helm Chart Release

  1. Update Chart.yaml (if not already done):

    cd charts/kube-mcp
# Edit Chart.yaml and update version
# Example: version: 0.0.2

  2. Commit and push:

    git add charts/kube-mcp/Chart.yaml
git commit -m "Bump chart version to 0.0.2"
git push origin main

  3. Create and push the chart tag:

    git tag chart-v0.0.2
git push origin chart-v0.0.2

  4. The .github/workflows/helm.yml workflow will:

    • Package the Helm chart
    • Push to oci://ghcr.io/cturner8/kube-mcp-chart
    • Create a draft GitHub release with auto-generated notes

  5. Review the generated release notes.

  6. Publish the release once ready.

The automated release is created in draft status to allow for review of generated release notes or to make any manual revisions.