name	upgrade-versions
description	Upgrade component versions in the project by checking GitHub releases and updating README and Helm manifests. Use when asked to bump, upgrade, update, or check versions of project components.
allowed-tools	Read, Bash, Glob, Grep

Upgrade Component Versions

This skill applies version updates from a pre-computed report. Read the report, then use sed via Bash to apply changes — do NOT use the Edit tool (it requires a prior Read per file, multiplying tool calls unnecessarily; sed works without reading the file first).

Prerequisites

.version-report.md must exist in the repo root (generated by the workflow step before this).

Steps

1. Read the version report

cat .version-report.md

2. Apply updates for rows marked YES

Skip these regardless:

provider-gcp-gke — track via upbound/provider-gcp-gke GitHub releases
Any row where latest_version is unknown

For each version that needs updating, run ONE sed command that covers all files containing that version string. Use find + xargs sed to update all files at once:

# Crossplane packages — version tag at end of spec.package URL
find kubernetes/ -name '*.yaml' ! -name 'gotk-components.yaml' \
  | xargs sed -i 's|:OLD_VERSION|:NEW_VERSION|g'

# Helm chart version field
sed -i 's|version: "OLD"|version: "NEW"|g' SPECIFIC_FILE

# README links — version appears in both link text and URL, one pass covers both
sed -i 's|OLD_VERSION|NEW_VERSION|g' README.md

Batch by version string: if function-auto-ready appears in 3 files all at v0.5.0, one find | xargs sed command updates all three simultaneously.

3. Also update README.md for YAML changes

For each helm or crossplane update, update the matching version link in README.md if the component appears in the tech-stack table (both link text and URL contain the version string, so a single sed -i 's|OLD|NEW|g' README.md handles both).

4. Validate version formats

Run the validator before committing:

bash scripts/validate-version-formats.sh

If it exits non-zero, read each error line. FORMAT_ERROR lines tell you exactly which file, what version string was expected, and what was actually written. Fix with sed:

# Example: expected 0.9.7 but wrote v0.9.7 in a file
sed -i 's|v0.9.7|0.9.7|g' path/to/file.yaml

Re-run the script after each fix to confirm it passes before proceeding.

5. Create a PR if any files changed

DATE=$(date -u +%Y-%m-%d)
BRANCH="chore/upgrade-versions-${DATE}"
git config user.email "github-actions[bot]@users.noreply.github.com"
git config user.name "github-actions[bot]"
git checkout -b "${BRANCH}"
git add -A
git commit -m "chore: upgrade component versions"
# Delete the remote branch if it exists from a prior same-day run, then push fresh.
# --force-with-lease won't work here because the local branch has no tracking ref.
git push origin --delete "${BRANCH}" 2>/dev/null || true
git push origin "${BRANCH}"
# Only create a PR if one doesn't already exist for this branch
EXISTING_PR=$(gh pr list --head "${BRANCH}" --state open --json number --jq '.[0].number' 2>/dev/null)
if [ -n "${EXISTING_PR}" ]; then
  echo "PR #${EXISTING_PR} already exists for ${BRANCH} — skipping create"
else
  gh pr create \
    --title "chore: upgrade component versions ${DATE}" \
    --body "$(printf '## Summary\n\n| Component | Old | New | Files |\n|---|---|---|---|\n...')" \
    --base main
fi

If nothing needed updating, just report that everything is up to date.

Notes

LitmusChaos: version from Helm index has no v prefix (3.26.0 not v3.26.0); match the format in the file. HelmRelease is at kubernetes/namespaces/base/litmus/helm/litmus-release.yaml — update the version: field there AND README.md
kagent / kgateway: version from GitHub has v prefix; match the format already in the file
FluxCD: update spec.distribution.version in all three flux-instance.yaml files (kind, control-plane, apps-dev) AND README.md. Version is a minor-pinned semver range (e.g. "2.8.x"). Use find kubernetes/ -name flux-instance.yaml | xargs sed -i. For a patch bump within the same minor, the operator auto-picks it up — only README needs updating. For a minor bump (e.g. 2.8.x → 2.9.x), update the version range in all three FluxInstance files and README.md.

name	upgrade-versions
description	Upgrade component versions in the project by checking GitHub releases and updating README and Helm manifests. Use when asked to bump, upgrade, update, or check versions of project components.
allowed-tools	Read, Bash, Glob, Grep