[PR] Release from a fresh clone, ask for the versions, and rotate the changelog [skywalking-helm]

["wu-sheng (via GitHub)" <gi...@apache.org>]

wu-sheng opened a new pull request, #198:
URL: https://github.com/apache/skywalking-helm/pull/198

   Three changes to the release tooling, plus the 5.0.0 changelog rotation they imply. **5.0.0 is already tagged and staged on svn** (`r87075`), so none of this affects the artifacts under vote — it applies from 5.1.0 onward, and lands 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. I verified it:
   
   ```
   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 the release. Hence three layers now: 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` can't 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.
   
   ## 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 — `yq -i .version` reindents every list in the document:
   
   ```
    chart/skywalking/Chart.yaml | 53 ++++++++++++++++++-----------------   <- yq
    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`/`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 version check still sees 5.0.0.
   
   ## Verified against a local fixture, not by reading
   
   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` |
   
   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 found in #197 by actually running the thing.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@skywalking.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Release from a fresh clone, ask for the versions, and rotate the changelog [skywalking-helm]

["wu-sheng (via GitHub)" <gi...@apache.org>]

wu-sheng merged PR #198:
URL: https://github.com/apache/skywalking-helm/pull/198


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@skywalking.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Release from a fresh clone, ask for the versions, and rotate the changelog [skywalking-helm]

["wu-sheng (via GitHub)" <gi...@apache.org>]

wu-sheng commented on PR #198:
URL: https://github.com/apache/skywalking-helm/pull/198#issuecomment-5469305997

   ### One more bug, found by an adversarial pass over `vote_mail`
   
   `vote_mail` runs *after* `prepare_next_version`, which has already moved the clone onto the `bump-to-*` branch — so `git rev-parse HEAD` there would cite the wrong commit. I had written the fallback as:
   
   ```bash
   commit=$(git rev-parse "${TAG}^{commit}" 2>/dev/null || git rev-parse master)
   ```
   
   which is broken for a reason I did not anticipate. `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 a vote mail with a two-line, broken URL:
   
   ```
    * https://github.com/apache/skywalking-helm/tree/v5.1.0^{commit}
   56ccedec787f3d36a94b9091b1621992a4c1ba40
   ```
   
   Fixed with `--verify --quiet`, which prints nothing and exits 1. Re-verified end to end — the mail now carries one hash, equal to the commit that was actually built:
   
   ```
    * https://github.com/apache/skywalking-helm/tree/731bbe7fa5f5f7f904529812e49448f6b26b25c0
     clone master (what was built): 731bbe7fa5f5f7f904529812e49448f6b26b25c0
   ```
   
   ### Also tested, because it was untested before
   
   The Makefile's `--exclude tools/releasing/skywalking-helm` was never exercised by my earlier run — `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 and running `make release-src`: the entries are absent from the tarball. Against master's Makefile the same file ships, which is the regression the exclude prevents.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@skywalking.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org