fd4c610aa1
release.py --publish always pushed to 'origin'. On a checkout with a fork remote wired for CI dry runs, that meant a dry-run publish could push a tag to the upstream repo — the tag push is what fires the release workflow, so the destination deserves an explicit choice. resolve_push_remote: one configured remote is used as-is; more than one requires --remote <name>; an unknown name or no remotes at all fail before any commit or tag exists. The gh release create call is pinned to the pushed remote's GitHub repo (--repo owner/name parsed from the remote URL) so gh cannot resolve a different remote than the one the tag landed on. |
||
|---|---|---|
| .. | ||
| test_build_skills_index_health.py | ||
| test_contributor_map.py | ||
| test_footgun_subprocess_encoding.py | ||
| test_release_tags.py | ||
| test_smoke_nemo_relay_shared_metrics.py | ||
| test_write_install_stamp.py | ||