Repository navigation
Conversation
Re-adds publish_native_windows_packages() to the release publish script, previously reverted in #8629 to fix the #8617 regression. The original #8097 implementation published to core/packages/msi/, which does not match RFC0012: per the repo-structure RFC, Windows installer artifacts (.exe/.msi) belong under core/windows-installers/, not core/packages/. Addresses marbre's post-merge review comment on #8097 (discussion_r4145328177). The current MSI is a single OS-agnostic installer, so it is published to a flat windows-installers/ prefix (dated subdir for dev/nightly, stable path for prerelease) rather than the per-OS subfolders (win11/, server2022/, server2025/) RFC0012 reserves for OS-specific installers — our MSI payload is identical across Windows versions. NOTE: do not merge until the MSI build workflow (multi_arch_build_native_windows_packages.yml) is wired into the release pipeline (Milestone 4, #1987). Publishing hard-fails on zero MSI files; merging this alone, while the build has no callers, reintroduces #8617. Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com>
✅ All Policy Checks Passed
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🎉 All checks passed! This PR is ready for review. |
ScottTodd
left a comment
ScottTodd
left a comment
There was a problem hiding this comment.
⚠️ Do not merge yetThe MSI build workflow (
multi_arch_build_native_windows_packages.yml) is still wired into nothing (0 callers).publish_native_windows_packages()hard-fails on zero MSI files — so merging this alone would reintroduce #8617 on the next nightly Windows release.This PR must land together with (or after) the Milestone 4 wiring that calls the MSI build workflow from the release pipeline (#1987). Held as a draft until then.
This PR is not a draft. What sort of review are you looking for here?
…stone 4) The MSI build workflow (multi_arch_build_native_windows_packages.yml) existed but had no callers — the gap behind the #8617 regression. Wire it into both Windows workflows per Milestone 4 (#1987), with the build/publish distinction each needs: - multi_arch_ci_windows.yml (nightly): add build_native_msi_packages, which builds the runtime MSI from this run's artifacts and uploads it to the run's artifacts bucket (a build artifact). No release-bucket publish in CI. - multi_arch_release_windows.yml (release cut): add build_native_msi_packages, make publish_to_release_buckets depend on it (so the MSIs exist before publish copies them to the release bucket — the dependency edge that prevents #8617), and add trigger_test_native_windows_install, which dispatches the MSI install test against this run's artifacts prefix. Both jobs added to notify_quartz_completed's needs. Only the runtime package is wired (packages: runtime); core's Windows artifacts are not yet published in nightly runs. DRAFT: depends on #8704 (publish_native_windows_packages) and #8669 (test_native_windows_packages_install.yml), which are not yet on main. The workflow_dispatch_inputs test correctly flags the install-test dispatch until #8669 merges. Rebase and validate once both land. Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com>
was looking for code correctness and logic review.. #9025 should merge first though and is now ready for review |
|
Don't you need the code here for |
yeah to keep things simple and clean ill batch them |
Summary
Re-adds
publish_native_windows_packages()topublish_rocm_to_release_buckets.py, previously reverted in #8629 to fix the #8617 regression, with the destination path corrected per RFC0012.v5/rocm/core/packages/msi/. Per RFC0012 repo structure, Windows installer artifacts (.exe/.msi) belong undercore/windows-installers/, notcore/packages/. This addresses marbre's post-merge review comment on ci: Windows MSI build workflow + dev-bucket upload (Milestone 2) #8097 (discussion_r4145328177).win11/,server2022/,server2025/) for OS-specific installers. Our current MSI is a single OS-agnostic installer with an identical payload across Windows versions (same user-mode ROCm DLLs), so it publishes to a flatwindows-installers/prefix: a{date}-{run_id}subdir for dev/nightly, a stable path for prerelease (mirrors the native-Linux-packages scheme).The MSI build workflow (
multi_arch_build_native_windows_packages.yml) is still wired into nothing (0 callers).publish_native_windows_packages()hard-fails on zero MSI files — so merging this alone would reintroduce #8617 on the next nightly Windows release.This PR must land together with (or after) the Milestone 4 wiring that calls the MSI build workflow from the release pipeline (#1987). Held as a draft until then.
Test plan
pytest build_tools/github_actions/tests/publish_rocm_to_release_buckets_test.py— 14 passed;test_windows_copies_native_msi_packagesasserts thev5/rocm/core/windows-installers/{date}-{run_id}destination.workflow_dispatchonce the build workflow is wired in and producing MSIs.🤖 Generated with Claude Code