Release from a fresh clone, ask for the versions, and rotate the changelog

[wu-sheng]

Three changes to the release tooling, plus the 5.0.0 changelog rotation they imply.

5.0.0 is unaffected. It is already tagged at 6fe2c78 and staged on svn (r87075), so the artifacts under vote were built before any of this. These changes apply from 5.1.0 onward, and land the bump PR that release run did not yet know how to open.

1. release.sh clones the repo itself

It clones apache/skywalking-helm into tools/releasing/skywalking-helm/ and does everything there, so you run it from your own checkout, dirty or not.

make release-src archives the working tree, not HEAD. That was previously handled by refusing to run against a dirty tree — correct, but it puts the problem on the operator, and the obvious workaround is a trap. Verified rather than assumed:

with .claude gitignored, is the tree "clean" to preflight?   git sees .claude as clean
but does release-src still tar it into the source release?   SHIPPED: ./.claude/
                                                             SHIPPED: ./.claude/skills/x.md

tar does not read .gitignore, so ignoring a directory makes it invisible to the dirty-tree check while leaving it in a voted ASF release. Hence three layers: the Makefile excludes the clone, .gitignore keeps it out of commits, and verify_artifacts inspects the finished tarball for the clone, a stray .tgz, charts/ or Chart.lock.

2. Both scripts ask for the versions

=== Versions ===
  release version:  5.1.0   (from your checkout's chart/skywalking/Chart.yaml)
  next dev version: 5.2.0

  Are these correct? [y/N]

release-passed.sh cannot default from Chart.yaml — by the time a vote passes, master has moved on — so it reads what is actually staged in svn. Its arguments are now order-independent and the version optional (--dry-run 5.0.0, 5.0.0 --dry-run, --dry-run, or nothing). Both require plain MAJOR.MINOR.PATCH, since the values reach a git tag, an svn path and a branch name.

The tag guard queries the remote, not the local clone. This very checkout proves why the local one lies: Chart.yaml said 5.0.0 and v5.0.0 existed on origin but not locally, so a local check passes and the push fails after the entire build.

3. release.sh opens the next-version PR

As swck's does. It rotates changes.md → changes-$VERSION.md, renders a fresh one from the new docs/changes/changes.tpl, bumps Chart.yaml, and inserts the released version into the docs menu after Current Version so released versions stay newest-first.

The chart bump uses sed, not yq — measured, not assumed:

 chart/skywalking/Chart.yaml | 53 ++++++++++++++++++-----------------   <- yq reindents every list
 chart/skywalking/Chart.yaml |  2 +-                                   <- sed

The menu insert does use yq, which round-trips that file with a clean 6-line diff.

The 5.0.0 rotation, applied here

changes.md → changes-5.0.0.md, master to 5.1.0, and the Changelog menu entry becomes a catalog so released versions have somewhere to go.

This is a deliberate change of practice: master previously kept the released version until the next release prepared itself (v4.7.0, v4.8.0 and v4.9.0 all left it in place). Safe for publishing, because publish-helm.yaml checks out the tag on a release event, so its chart-version check still sees 5.0.0.

Two bugs this found, both by running the thing

The vote mail would have gone out with a broken URL. vote_mail runs after prepare_next_version, which has already moved the clone onto the bump-to-* branch, so git rev-parse HEAD cites the wrong commit. The obvious fallback is also wrong, because git rev-parse echoes an unresolvable ref back on stdout and exits 128:

$ git rev-parse "v9.9.9^{commit}" 2>/dev/null ; echo "rc=$?"
v9.9.9^{commit}
rc=128

So $(A || B) captured both, and the dry run emitted:

 * https://github.com/apache/skywalking-helm/tree/v5.1.0^{commit}
56ccedec787f3d36a94b9091b1621992a4c1ba40

Fixed with --verify --quiet, which prints nothing and exits 1. Re-verified: the mail now carries one hash, equal to the commit that was built.

The Makefile exclude was untested. My first end-to-end run never exercised it, because release-src runs inside the clone, which contains no nested clone. Tested directly by planting tools/releasing/skywalking-helm/deep/x.txt in a tree: absent from the tarball with this Makefile, shipped with master's.

Verified against a local fixture

A bare git origin plus an svnadmin repo standing in for dist/dev, so nothing touched production:

Full --dry-run	exit 0, all nine stages
Artifacts	six files, signatures and checksums verify
Chart	renders 33 resources
Source tarball	0 offending entries
svn staging	7 entries (dir + 6 files)
Next-version commit	Chart.yaml +1/-1, changes-5.1.0.md added, changes.md retitled, menu.yml +2
Menu order after rotation	Current Version, 5.1.0, 5.0.0
Vote mail commit	matches the built commit exactly

Guards were checked by firing them: run against the real repo with 5.0.0 and it stops at tag v5.0.0 already exists on the remote.

Every new guard is if-form rather than X && die, and the temp-dir cleanup stays at script scope — the two set -e/set -u bugs #197 found by actually running the thing.