chore: let the maintainer past the CLA, and fix what the release docs got wrong - #26
Conversation
… got wrong
The CLA check failed on every pull request from this repository's own
maintainer. The allowlist named `memtomem`, which owns the repository,
but commits are authored under an e-mail GitHub resolves to `tsdata`.
Both are the same person; both are allowlisted now.
Publishing 0.2.0 turned up two errors in what these documents claim, and
both cost a failed run today rather than being spotted by reading.
The token scopes were wrong. The checklist asked for Pull requests
*read*, derived from the endpoints the script calls -- it posts to
`/issues/{n}/comments`, which reads like an Issues permission. When that
number is a pull request GitHub enforces the Pull requests permission
instead, and the token fails with `Resource not accessible by personal
access token` until it has write. Issues write alone is not enough; the
documentation now says so and says why.
The Trusted Publisher form's "Environment name" is the GitHub
environment, not the index. Filled in as `testpypi` on TestPyPI it
produced `invalid-publisher: valid token, but no corresponding
publisher`, because one environment named `pypi` serves both indexes and
the tag decides where a run uploads. The runbook now states that, and
that a pending publisher has to be removed and re-added rather than
edited.
The recovery section gained the fact that made that failure cheap: a
publisher mismatch fails at the token exchange, before any upload, so
the index never sees the version and the number is not consumed. The
question worth asking is which step a release failed at, not whether it
is reversible.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hkm75k7g4Eaq5YvkHGgRzW
|
Thank you for your contribution! Before we can merge, please sign the Contributor License Agreement. Missing signature(s): To sign, comment on this pull request with the statement below. You only need to sign once per GitHub account.
|
1 similar comment
|
Thank you for your contribution! Before we can merge, please sign the Contributor License Agreement. Missing signature(s): To sign, comment on this pull request with the statement below. You only need to sign once per GitHub account.
|
7c10413 to
bc26c53
Compare
|
Thank you for your contribution! Before we can merge, please sign the Contributor License Agreement. Missing signature(s): To sign, comment on this pull request with the statement below. You only need to sign once per GitHub account.
|
The previous commit stated a rule: that GitHub enforces the Pull requests permission when an issue-comment endpoint is called with a pull request number. GitHub's own documentation says the endpoint accepts either Issues write or Pull requests write, so the 403 seen here does not establish that rule -- a permission change that had not propagated yet produces the same symptom, and the token's effective permissions were never read back between the two attempts. What is recorded now is only what happened: with Issues at write and Pull requests at read the comment failed, and raising Pull requests to write cleared it, cause unestablished. The recommendation is unchanged, because granting all three as write makes the question moot for whoever sets this up next. Found by the review gate, which checked the claim against the endpoint's documentation rather than against the error message. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hkm75k7g4Eaq5YvkHGgRzW
bc26c53 to
286e640
Compare
|
Thank you for your contribution! Before we can merge, please sign the Contributor License Agreement. Missing signature(s): To sign, comment on this pull request with the statement below. You only need to sign once per GitHub account.
|
2 participants
Follow-up to publishing 0.2.0. No code; the published package is untouched.
The check on this pull request stays red, and that is expected.
cla.ymlruns onpull_request_target, which checks out the default branch and runs its copy of theworkflow — never the pull request's. The run on this branch used
ref: tracegraph-mvpandthe old allowlist, as its log shows. The change can only take effect once it is on the
default branch, so the first pull request after this one is what demonstrates it.
What changes
.github/workflows/cla.yml—tsdatajoins the allowlist. The check failed on everypull request from this repository's own maintainer: the allowlist named
memtomem,which owns the repository, but commits are authored under an e-mail GitHub resolves to
tsdata. Same person.docs/public-release-checklist.md— the personal access token needs Pull requests:read/write, not read. The script posts to
/issues/{n}/comments, which reads like anIssues permission, but when that number is a pull request GitHub enforces the Pull
requests one. Measured: the token returns
Resource not accessible by personal access tokenwith Issues write alone.docs/releasing.md— a Trusted Publisher's "Environment name" is the GitHubenvironment, not the index. One environment named
pypiserves both, because the tagdecides where a run uploads. Filled in as
testpypi, the first 0.2.0 rehearsal failedwith
invalid-publisher: valid token, but no corresponding publisher. A pendingpublisher cannot be edited field by field; remove and re-add.
OIDC token exchange, before any upload, so the version is not consumed. Re-run the same
tag.
Both documentation errors cost a failed run today rather than being caught by reading them.
Next
Once the check here is green,
CLAAssistantcan go into the required status checks. Notewhat that commits to: signing is an
issue_commentevent, which GitHub records againstthe default branch, so an external contributor's signature does not clear the red check on
their own pull request. A maintainer re-runs the head-SHA workflow. That is why the
sibling repositories keep the check visible but not required.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Hkm75k7g4Eaq5YvkHGgRzW