# Bump Kubetail

> Bump kubetail components (dashboard, cluster-api, cluster-agent) to their latest releases and update config variables

- Skill: `kubetail-org/bump-kubetail` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kubetail-org/bump-kubetail`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kubetail-org/bump-kubetail/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: kubetail-org (https://skillmd.com/u/kubetail-org)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kubetail-org/bump-kubetail

---


# Bump Kubetail Skill

Bump the kubetail components (dashboard, cluster-api, cluster-agent) to their latest releases and update config variables as needed.

## Context

The helm-charts repo manages the `kubetail` Helm chart with three main components:

| Component     | Image tag location in values.yaml | Config struct source                       |
| ------------- | --------------------------------- | ------------------------------------------ |
| dashboard     | `kubetail.dashboard.image.tag`    | `modules/dashboard/pkg/config/config.go`   |
| cluster-api   | `kubetail.clusterAPI.image.tag`   | `modules/cluster-api/pkg/config/config.go` |
| cluster-agent | `kubetail.clusterAgent.image.tag` | `crates/cluster_agent/src/config.rs`       |

The source code is available at https://github.com/kubetail-org/kubetail. Git tags follow the pattern `<component>/v<semver>` (e.g., `dashboard/v0.10.1`, `cluster-api/v0.5.3`, `cluster-agent/v0.6.2`).

Runtime config for each component is rendered via Helm ConfigMap templates:

| Component     | ConfigMap template                                        | Values path                           |
| ------------- | --------------------------------------------------------- | ------------------------------------- |
| dashboard     | `charts/kubetail/templates/dashboard/config-map.yaml`     | `kubetail.dashboard.runtimeConfig`    |
| cluster-api   | `charts/kubetail/templates/cluster-api/config-map.yaml`   | `kubetail.clusterAPI.runtimeConfig`   |
| cluster-agent | `charts/kubetail/templates/cluster-agent/config-map.yaml` | `kubetail.clusterAgent.runtimeConfig` |

## Steps

### 1. Ensure the helm-charts branch is up-to-date

First, determine which remote points to `kubetail-org/helm-charts`:

```bash
git remote -v | grep 'kubetail-org/helm-charts.*fetch'
```

Use that remote name (e.g., `origin`, `upstream`, etc.) for all subsequent commands. Call it `<remote>`.

Then run in parallel:

- `git fetch <remote>`
- Check the current branch name with `git branch --show-current`

Then check if the current branch is behind `<remote>/main`:

```bash
git log HEAD..<remote>/main --oneline
```

- If there are commits the current branch doesn't have, warn the user and stop -- they should rebase/merge before proceeding.

### 2. Determine current versions

Read `charts/kubetail/values.yaml` and extract the current image tags:

- `kubetail.dashboard.image.tag` (e.g., `"0.10.1"`)
- `kubetail.clusterAPI.image.tag` (e.g., `"0.5.3"`)
- `kubetail.clusterAgent.image.tag` (e.g., `"0.6.2"`)

### 3. Find latest versions

Use the GitHub API to list tags for each component:

```bash
gh api repos/kubetail-org/kubetail/git/matching-refs/tags/dashboard/v --jq '.[].ref' | sed 's|refs/tags/dashboard/v||' | grep -v '\-rc' | sort -V | tail -1
gh api repos/kubetail-org/kubetail/git/matching-refs/tags/cluster-api/v --jq '.[].ref' | sed 's|refs/tags/cluster-api/v||' | grep -v '\-rc' | sort -V | tail -1
gh api repos/kubetail-org/kubetail/git/matching-refs/tags/cluster-agent/v --jq '.[].ref' | sed 's|refs/tags/cluster-agent/v||' | grep -v '\-rc' | sort -V | tail -1
```

Take the highest non-rc version for each component.

### 4. Check for config changes

For each component where the version has changed, use the GitHub compare API to diff the config struct between the old and new tags:

**Dashboard (Go):**

```bash
gh api repos/kubetail-org/kubetail/compare/dashboard/v<old>...dashboard/v<new> --jq '.files[] | select(.filename == "modules/dashboard/pkg/config/config.go") | .patch'
```

**Cluster API (Go):**

```bash
gh api repos/kubetail-org/kubetail/compare/cluster-api/v<old>...cluster-api/v<new> --jq '.files[] | select(.filename == "modules/cluster-api/pkg/config/config.go") | .patch'
```

**Cluster Agent (Rust):**

```bash
gh api repos/kubetail-org/kubetail/compare/cluster-agent/v<old>...cluster-agent/v<new> --jq '.files[] | select(.filename == "crates/cluster_agent/src/config.rs") | .patch'
```

Also fetch the current config struct at the new tag and read the current Helm ConfigMap template + values to understand all available options:

```bash
gh api repos/kubetail-org/kubetail/contents/<path>?ref=<component>/v<new> --jq '.content' | base64 -d
```

### 5. Assess config changes

For each config diff:

- If the diff is empty or only contains trivial changes (comments, formatting), proceed to image tag updates.
- If there are **new config fields**: check if they map cleanly to existing `runtimeConfig` values structure. If the new fields can be added as simple key-value pairs under the existing `runtimeConfig` hierarchy, propose the additions.
- If there are **removed config fields**: propose removing them from `runtimeConfig` in values.yaml.
- If the config changes require **non-trivial template modifications** (new template logic, conditionals, structural changes to ConfigMap rendering, new Kubernetes resources, etc.): **stop and tell the user** that a manual chart update is needed. Explain what changed and why it can't be handled by a simple bump.

Collect all proposed config changes and **present them to the user for approval** before making any edits. Show a clear diff-like summary of what will change.

### 6. Apply approved changes

After the user approves (or modifies) the config proposals:

1. **Update image tags** in `charts/kubetail/values.yaml` -- replace the old tag value with the new one for each component that changed.
2. **Apply config changes** to `charts/kubetail/values.yaml` -- add/remove/modify `runtimeConfig` fields as approved.
3. **Update `charts/kubetail/Chart.yaml`** — determine the bump severity by looking at the semver change across all components:
   - If any component has a **major** version bump → bump `appVersion` and `version` major.
   - If any component has a **minor** version bump → bump `appVersion` and `version` minor.
   - If all component changes are **patch** only → bump `appVersion` and `version` patch.

   Both `version` and `appVersion` get the same bump level and stay in sync.

### 7. Report

Summarize what was changed:

- List each component: old version -> new version (or "no change")
- List any config keys added or removed
- Note the new chart `version` and `appVersion`

## Rules

- NEVER skip the user approval step for config changes.
- Only bump components where the latest tag is newer than the current version.
- If a component is already at the latest version, mention it but make no changes.
- Exclude release candidate tags (those containing `-rc`) when determining the latest version.
- If config changes require non-trivial template modifications, bail out and explain what needs to be done manually.
- Make best-effort guesses for new config values based on context (existing config patterns, field names, defaults in the source struct). Acknowledge uncertainty where it exists.
- Do NOT guess secret values -- for fields that are clearly secrets (keys, passwords, tokens), note them as `<REPLACE_ME>` and call them out to the user.
- When reading Go config structs, pay attention to `validate:"required"` tags -- these fields must have values.
- When reading Rust config structs, pay attention to `#[serde(default)]` and `Option<T>` types to determine which fields are optional.
- Run all independent git/read operations in parallel for speed.