You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@skywalking.apache.org by "wu-sheng (via GitHub)" <gi...@apache.org> on 2026/08/31 09:10:48 UTC
[PR] Add a read-only Docker Hub auth check [skywalking-helm]
wu-sheng opened a new pull request, #200:
URL: https://github.com/apache/skywalking-helm/pull/200
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`.
--
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] Add a read-only Docker Hub auth check [skywalking-helm]
Posted by "wu-sheng (via GitHub)" <gi...@apache.org>.
wu-sheng closed pull request #200: Add a read-only Docker Hub auth check
URL: https://github.com/apache/skywalking-helm/pull/200
--
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] Add a read-only Docker Hub auth check [skywalking-helm]
Posted by "wu-sheng (via GitHub)" <gi...@apache.org>.
wu-sheng commented on PR #200:
URL: https://github.com/apache/skywalking-helm/pull/200#issuecomment-5476248239
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.
--
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