ci: idempotent PyPI publish re-runs; fix stale branch-strategy review docs#2886
Conversation
… docs - uv publish --check-url: the rc publish uploaded the SDK wheel and then failed on bittensor-core (missing trusted publisher); a plain re-run would 400 on the duplicate wheel. --check-url skips files already on the index so re-runs after partial uploads just resume. - copilot-instructions.md still described the pre-release-train branch strategy (PRs target devnet); the auditor cited it to block a routine PR against main. Align it with common.md: PRs target main, the network branches are ruleset-locked CI mirrors. Co-authored-by: Cursor <cursoragent@cursor.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
IntiTechnologies
left a comment
IntiTechnologies
left a comment
There was a problem hiding this comment.
CI/docs-only hardening from the first rc-channel run.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| * All PRs target `main`. Deployment is automated, not PR-driven: merges to `main` ride the release train, which promotes devnet → testnet → mainnet via on-chain `setCode` (see `docs/internals/release-process.mdx`) | ||
| * `devnet`, `testnet`, and `mainnet` are CI-managed mirror branches recording what each network currently runs; they are ruleset-locked and only the release train updates them | ||
| * Flag any PR that targets `devnet`, `testnet`, or `mainnet` — those branches never receive merges |
There was a problem hiding this comment.
[HIGH] Trusted review instructions are modified by the PR
This changes the AI review control plane relative to the trusted base copy. Although the new branch policy is consistent with trusted common.md and appears benign, changes to .github/copilot-instructions.md must be treated as HIGH risk. Land this through the repository's dedicated trusted-instruction review process with explicit nucleus verification.
🛡️ AI Review — Skeptic (security review)VERDICT: VULNERABLE MEDIUM scrutiny: ~4-month-old contributor with write permission and substantial activity; no Gittensor association found. Branch release-train-hardening -> main. Static review found no security issue in the two Findings
ConclusionThe release workflow hardening appears safe, but this PR modifies trusted AI-review instructions and therefore requires a HIGH control-plane finding under the review policy. # 🔍 AI Review — Auditor (domain review) has not yet run on this PR. |
|
🔄 AI review updated — Skeptic: VULNERABLE |
2 participants
Summary
Two seamlessness fixes from the first live run of the rc channel:
uv publish --check-urlinrelease-train.ymlandwatch-mainnet-release.yml: run 29222052755 uploadedbittensor 11.0.0rc6and then failed onbittensor-core(no trusted publisher for the not-yet-existing project). A plain re-run would 400 on the already-uploaded wheel;--check-urlskips identical files already on the index, making publish re-runs resume instead of fail.copilot-instructions.mdbranch strategy: still described the pre-release-train world ("all PRs must targetdevnet"), which the AI auditor cited to block a routine PR againstmain(sdk: declare readme and point Documentation at bittensor.com/docs #2866). Rewritten to matchai-review/common.md: PRs targetmain;devnet/testnet/mainnetare ruleset-locked CI mirrors.Related ops changes made directly (not in this diff): stale classic branch protections on
testnetanddevnetdeleted — they predate the mirror ruleset and the testnet one blocked the deploy-key mirror push on the first real testnet deploy.Test plan
Made with Cursor