Publish the voted chart, write real release notes, fix the ANNOUNCE link - #199
Merged
Conversation
The mail pointed at /docs/skywalking-helm/${VERSION}/readme/, but the site
publishes version-pinned docs under the tag, v-prefix included -- data/docs.yml
declares `link: /docs/skywalking-helm/v5.0.0/readme/`. Checked both:
404 https://skywalking.apache.org/docs/skywalking-helm/5.0.0/readme/
200 https://skywalking.apache.org/docs/skywalking-helm/v5.0.0/readme/
That mail goes to announce@apache.org, so the dead link would have been the most
widely read thing in the release.
Also drops the stale instruction to repoint data/docs.yml at this repository --
that entry now reads `repo: skywalking-helm` with a repoUrl, and the docs are
live. What the next release actually needs there is a new version entry and a
`Latest` commitId, so the note says that instead.
The release path ran `make package` and pushed the result. That is not the
artifact the PMC voted on: `helm dep up` re-resolves the subcharts at package
time, so a chart packaged later can embed different dependency content than the
one under vote. Measured on 5.0.0 -- same tag, same Makefile, different bytes:
voted sha256 29ef163c285575aefad4a7a20d2cfd8f79005cc6f5e7668416e689ba82eea99e
rebuilt sha256 189d07a86913626cfda0d4f5899f3c611fc4c36eb27ec2c285e5db106db8f2b7
So the release path now downloads skywalking-helm-$VERSION.tgz from
dist/release, verifies its detached signature against the published KEYS file
and its sha512, checks the packaged Chart.yaml really says $VERSION, checks
LICENSE and NOTICE are inside, and pushes that. dist.apache.org rather than
downloads.apache.org: the release area is authoritative and immediate, while the
mirror lags an svn commit by some time. Snapshots keep building from the tree --
there is no voted artifact to copy.
Adds workflow_dispatch, following skywalking-swck, which takes the same input
for the same reason. A re-run replays the workflow file as of the ORIGINAL run's
commit, not master, so when a release publish fails and the fix lands afterwards
re-running still uses the broken file. Dispatching runs the current one. No
schedule: neither swck nor apache/skywalking has one, and a cron that pushes
released versions would only ever republish immutable content.
Also fixes the ANNOUNCE mail's documentation link. It built
/docs/skywalking-helm/${VERSION}/readme/, but the site publishes version-pinned
docs under the tag, v-prefix included:
404 https://skywalking.apache.org/docs/skywalking-helm/5.0.0/readme/
200 https://skywalking.apache.org/docs/skywalking-helm/v5.0.0/readme/
That mail goes to announce@apache.org. Drops the stale note telling the release
manager to repoint data/docs.yml at this repository, which is done.
Verified against the real release area: all three files fetch, the signature is
good, the checksum matches, the packaged version is 5.0.0, LICENSE and NOTICE
are present, and the fetched file is byte-identical to the voted artifact.
wu-sheng
changed the title
wankai123
approved these changes
Aug 31, 2026
wu-sheng
changed the title
This was referenced Aug 31, 2026
wu-sheng
added a commit
that referenced
this pull request
Aug 31, 2026
* Put the whole changelog in the GitHub release, not a link to it The release body was one line: "See .../docs/changes/changes.md". Nobody follows a link to find out what changed in the release they are already looking at, and every release before this one carried its notes inline -- 4.7.0 through 4.9.0 all have the generated "What's Changed" list on the page. github_release now assembles the body before publishing anything: the curated "## $VERSION" section from the changelog, followed by GitHub's own generated list of merged PRs and new contributors. Assembled here rather than passed as --generate-notes so the exact text is known before it is published. Two details that only show up by looking at the result. The changelog's links are relative -- ../upgrade/upgrading.md resolves inside docs/ and 404s on a release page -- so they are rewritten to the hosted docs for the tag, and all six were checked to return 200. And the section is read from changes-$VERSION.md when the next-version PR has already merged, falling back to changes.md when it has not, because release-passed.sh can run either side of that merge. A version with no matching section logs a warning and falls back to the old link rather than failing: this runs after the artifacts are already promoted, so it is the wrong place to abort. Verified by running the function itself, not a copy: for 5.0.0 it reproduces the notes now published on the release page, and for a version with no section it takes the fallback. * Authenticate to Docker Hub the way apache/skywalking does apache/skywalking's publish-docker sets DOCKER_REGISTRY=docker.io and pushes the bare reference $(HUB)/$(NAME):$(TAG) -- apache/skywalking-oap-server -- and that repository publishes to Docker Hub from CI without trouble. This one used the explicit endpoint form on both halves: login to registry-1.docker.io, push to oci://registry-1.docker.io/apache. Both hosts serve the same registry, and `helm show chart` reads our own published 4.8.0 through either. What differs is where the credential lands: `docker login docker.io` stores it under Docker Hub's canonical key, "https://index.docker.io/v1/", while logging into registry-1.docker.io stores it under that literal host. Only the first is the key every other apache repository authenticates with. This is not proven to be the cause of the 401 -- an anonymous token request for repository:apache/skywalking-helm:pull,push returns 200, so a credential the client failed to find would have produced an anonymous token rather than a rejection, which points at authorization on the Docker Hub side. But it is a real difference from a known-good setup, it costs nothing to remove, and leaving the org on two different forms is worse than picking the one that is known to work. * Use docker.io everywhere, never registry-1.docker.io This is what broke the 5.0.0 chart publish, and the swck repository hit the same bug independently. `docker login <host>` stores the credential under the host you name. `helm push` then normalises back to Docker Hub's canonical host and looks there, finding nothing. Both hostnames PULL anonymously without complaint -- the chart's own BanyanDB dependency resolves through either, verified, same digest -- so the mismatch stays invisible until a push with credentials. That is the one operation this repository had never exercised: every release through 4.8.0 was pushed by hand, and CI's Docker Hub path only existed from 5.0.0. apache/skywalking's publish-docker has always used docker.io with a bare apache/<name> push target, and publishes without trouble. Swept all 46 occurrences across 25 files, not just the workflow, so the hostname a user copies out of the docs is the one we publish to: the Makefile's `publish` target, the chart's own dependency repository, README, chart README, and every install and upgrade example. Verified after the change: `helm dep up` pulls skywalking-banyandb-helm 0.7.0 through oci://docker.io/apache at the identical digest, `make package` succeeds, the packaged chart renders 33 resources and bundles the subchart, and the docs links and menu still resolve. An earlier comment in this workflow justified registry-1.docker.io on the grounds that it was simply the explicit endpoint form. That was not a verified claim, and it read as deliberate when it was not.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three fixes to the release tail, all found by running the tooling against the real 5.0.0 release.
1. The release page had a link instead of release notes
The body was one line —
See .../docs/changes/changes.md. Nobody follows a link to find out what changed in the release they are already looking at, and every release before this one carried its notes inline: 4.7.0, 4.8.0 and 4.9.0 all show the generatedWhat's Changedlist.github_releasenow assembles the body before publishing: the curated## $VERSIONsection of the changelog, then GitHub's generated list of merged PRs and new contributors. Assembled in the script rather than passed as--generate-notes, so the exact text is known before anything is published.Two details that only surface by looking at the output:
../upgrade/upgrading.mdresolves insidedocs/and 404s on a release page, so they're rewritten to the hosted docs for the tag. All six verified 200.changes-$VERSION.mdonce the next-version PR has merged, falling back tochanges.mdbefore that —release-passed.shcan run either side of that merge.A version with no matching section logs a warning and falls back to the old link rather than failing. This runs after the artifacts are promoted, so aborting there would be the wrong call.
v5.0.0's release page has already been updated by hand to what this produces.
2. The release path published a rebuild, not the voted artifact
publish-helm.yamlranmake packageand pushed the result. That is not what the PMC voted on —helm dep upre-resolves subcharts at package time. Same tag, same Makefile, different bytes:It now downloads
skywalking-helm-$VERSION.tgzfromdist/releaseand verifies signature,sha512, packaged version and the presence ofLICENSE/NOTICEbefore pushing.dist.apache.org, notdownloads.apache.org— the release area is authoritative and immediate, the mirror lags an svn commit. Snapshots still build from the tree; there is no voted artifact to copy.Also adds
workflow_dispatch(tag, as swck's does), because a re-run replays the workflow file as of the original run's commit, not master — so a publish that failed before this fix can only be retried through a dispatch. No schedule: neither swck norapache/skywalkinghas one, and a cron pushing released versions would only republish immutable content.3. The ANNOUNCE mail's documentation link was dead
The site publishes version-pinned docs under the tag. That mail goes to
announce@apache.org. Also drops the staleremaining()note about repointingdata/docs.yml— done, and the docs are live.Verified by running it
dist/release/.../5.0.0/build_release_notesfor 5.0.0build_release_notesfor a version with no section