Stop rebuilding the Helm index from scratch on every release

[mbakalarski]

The defect

helm repo index --merge takes a file path, not a URL. release-on-tag.yaml handed it a URL:

helm repo index .cr-index --url "${repo_url}" \
  --merge https://netclab.github.io/netclab-chart/index.yaml || true

helm merges nothing and exits 0, so || true was hiding nothing — helm itself reported success. Reproduced with helm v4.1.3:

--merge argument	result
URL	exit 0, merge silently skipped
file path	exit 0, merged correctly

Every release therefore published an index containing exactly one chart.

The damage

The published index listed 1 version (0.5.11) while 15 releases carry tarballs, back to v0.3.2:

helm search repo netclab --versions          →  0.5.11 only
helm show chart netclab/netclab --version 0.5.9
  Error: no chart version found for netclab-0.5.9
curl …/releases/download/v0.5.9/netclab-0.5.9.tgz   →  200

Nothing was lost — urls: points at GitHub Releases, and the tarballs are all there — but helm could not see them. It went unnoticed because every consumer pins the newest version, which was the one version in the index.

Already repaired on gh-pages (a14fcd2): the index now holds all 15 versions, 0.3.2 → 0.5.11, each pointing at its own release. This PR fixes the cause.

The fix

• Fetch the index to a file with curl -fsSL, then --merge that file, with an else branch for the first-ever release.
• Drop || true, so a genuine failure fails the release rather than publishing a truncated index.
• New step "Refuse to publish an index that lost versions", comparing the entry count before and after.

Verification

path	before → after	guard
fixed command, new chart	15 → 16, correct per-version URL	passes
old command (regression)	15 → 1	blocks the publish

yq is preinstalled on ubuntu-24.04 (4.53.3) — checked rather than assumed, since nothing else in this repo's CI uses it and a failure in this step would break a release after the tag.

The index URL deliberately stays on netclab.github.io: it works today and keeps working after the domain move through a 301 that curl -L follows, so this fix does not wait on the site migration.

🤖 Generated with Claude Code