Add a read-only Docker Hub auth check

[wu-sheng]

The 5.0.0 chart push fails with 401 from auth.docker.io for repository:apache/skywalking-helm:pull,push, and INFRA reports the configuration as correct. Both cannot be acted on without knowing what the CI credential itself gets back — and only a workflow run can ask that.

Two baselines, measured from outside

request	result
anonymous	200, granted=pull — a reduced scope, not a refusal
deliberately bad credentials	401 — the signature CI saw

This corrects an earlier reading of the failure I gave. I had taken "anonymous returns 200" to mean the 401 must be a permission refusal. It doesn't: a 200 does not mean push was granted. A client that failed to find its credential would have received a pull-only token and died later at the blob upload — not at this endpoint. CI failing here has the signature of credentials sent and rejected.

What it does

Asks for the same scope on the repository that fails and on one the same credential is known to push to — apache/skywalking-oap-server, whose release publish succeeded 2026-08-28 — and prints the answers side by side:

  anon    apache/skywalking-helm              http=200   granted=pull
  auth    apache/skywalking-helm              http=???   granted=???
  anon    apache/skywalking-oap-server        http=200   granted=pull
  auth    apache/skywalking-oap-server        http=???   granted=???

auth rows	conclusion
401 on helm, 200 pull,push on oap-server	credential is good; per-repository permission on Docker Hub
401 on both	the credential itself is rejected — the token, not the repository
200 pull only	authenticated and accepted, but read-only there
200 pull,push on helm	auth is fine now — re-run publish-helm with tag: v5.0.0

Either way the next step stops being a guess, and the output is something concrete to hand back to INFRA.

Safety

Publishes nothing, pushes nothing, writes nothing. No set -x; every curl discards its body; the only things printed are an HTTP status and the token's access claim, which describes the repository's permissions, not the identity. Dispatch-only.

Meant to be deleted once the question is settled — that's stated at the top of the file.

Verified

Extracted the step's shell from the YAML and ran it: parses clean, the anonymous path works, the JWT access decode works, and stub credentials reproduce the 401.

[wu-sheng]

Closing — the question this was built to answer has been answered.

The swck repository hit the identical bug and tested it there: the credential is stored under the host you log in as, while helm push normalises back to Docker Hub's canonical host and finds nothing. Both hostnames pull anonymously without complaint, which is why it stays invisible until a push with credentials.

So it is not per-repository permission on Docker Hub, and INFRA's "configured correctly" was right. No diagnostic needed.

The fix — docker.io throughout, matching apache/skywalking — plus the two commits lost from #199's squash are in a follow-up PR.