Refine CI workflows and expand packaging coverage#1892
Conversation
There was a problem hiding this comment.
💡 Codex Review
rsync/xtask/src/commands/release/upload.rs
Lines 228 to 236 in 64a08a1
The CI matrix now builds Windows artifacts for x86_64-pc-windows-msvc (and enables windows-aarch64), but the release uploader still resolves Windows targets to x86_64-pc-windows-gnu/i686-pc-windows-gnu. Running cargo xtask release upload will therefore search target/*-pc-windows-gnu for the binaries that CI never produces anymore and fail to upload the Windows artifacts. Align the mapping with the new MSVC targets (or handle both) so the release packaging step can locate the generated binaries.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Expand the placeholder async migration plan into a comprehensive, opinionated design covering: current synchronous threading model per subsystem, per-subsystem cost/benefit, a phased incremental adoption strategy, tokio runtime choice with rejected alternatives, sync/async bridge patterns, backward-compat strategy, risk register, and open questions. Cross-references existing async-related tasks (#1367, #1411, #1591, #1593, #1595, #1674, #1751, #1779, #1780, #1782, #1796, #1797, #1805, #1806, #1889, #1890, #1891, #1892, #1934, #1935, #2136) and related design notes so future planners have a single anchor.
Expand the placeholder async migration plan into a comprehensive, opinionated design covering: current synchronous threading model per subsystem, per-subsystem cost/benefit, a phased incremental adoption strategy, tokio runtime choice with rejected alternatives, sync/async bridge patterns, backward-compat strategy, risk register, and open questions. Cross-references existing async-related tasks (#1367, #1411, #1591, #1593, #1595, #1674, #1751, #1779, #1780, #1782, #1796, #1797, #1805, #1806, #1889, #1890, #1891, #1892, #1934, #1935, #2136) and related design notes so future planners have a single anchor.
…, and explicit backpressure (#4272) Three followup design notes to the umbrella SSH async I/O eval: - ssh-async-default-linux.md (#1890): trigger conditions and 5-step rollout to flip the Linux default from sync to async, with the feature/cfg gate and the OC_RSYNC_SSH_ASYNC=0 escape hatch. - ssh-decouple-delta-from-socket-read.md (#1891): split the SSH read thread from the delta applier via a bounded crossbeam-channel queue; MSG_DATA / MSG_INFO ordering preserved, error propagation via a oneshot channel, queue-depth defaults explained. - ssh-explicit-backpressure-controls.md (#1892): user-facing --ssh-max-in-flight-bytes flag and OC_RSYNC_SSH_MAX_IN_FLIGHT_BYTES env var, implemented as a tokio Semaphore at the multiplex writer and receiver-side queue, default 4 MiB, with the max(N, MAX_PAYLOAD_LENGTH) floor that avoids single-frame deadlock. Each doc lists 5-step impl plan plus trigger conditions and ties back to the umbrella eval's recommendation.
Expand the placeholder async migration plan into a comprehensive, opinionated design covering: current synchronous threading model per subsystem, per-subsystem cost/benefit, a phased incremental adoption strategy, tokio runtime choice with rejected alternatives, sync/async bridge patterns, backward-compat strategy, risk register, and open questions. Cross-references existing async-related tasks (#1367, #1411, #1591, #1593, #1595, #1674, #1751, #1779, #1780, #1782, #1796, #1797, #1805, #1806, #1889, #1890, #1891, #1892, #1934, #1935, #2136) and related design notes so future planners have a single anchor.
…, and explicit backpressure (#4272) Three followup design notes to the umbrella SSH async I/O eval: - ssh-async-default-linux.md (#1890): trigger conditions and 5-step rollout to flip the Linux default from sync to async, with the feature/cfg gate and the OC_RSYNC_SSH_ASYNC=0 escape hatch. - ssh-decouple-delta-from-socket-read.md (#1891): split the SSH read thread from the delta applier via a bounded crossbeam-channel queue; MSG_DATA / MSG_INFO ordering preserved, error propagation via a oneshot channel, queue-depth defaults explained. - ssh-explicit-backpressure-controls.md (#1892): user-facing --ssh-max-in-flight-bytes flag and OC_RSYNC_SSH_MAX_IN_FLIGHT_BYTES env var, implemented as a tokio Semaphore at the multiplex writer and receiver-side queue, default 4 MiB, with the max(N, MAX_PAYLOAD_LENGTH) floor that avoids single-frame deadlock. Each doc lists 5-step impl plan plus trigger conditions and ties back to the umbrella eval's recommendation.
Expand the placeholder async migration plan into a comprehensive, opinionated design covering: current synchronous threading model per subsystem, per-subsystem cost/benefit, a phased incremental adoption strategy, tokio runtime choice with rejected alternatives, sync/async bridge patterns, backward-compat strategy, risk register, and open questions. Cross-references existing async-related tasks (#1367, #1411, #1591, #1593, #1595, #1674, #1751, #1779, #1780, #1782, #1796, #1797, #1805, #1806, #1889, #1890, #1891, #1892, #1934, #1935, #2136) and related design notes so future planners have a single anchor.
…, and explicit backpressure (#4272) Three followup design notes to the umbrella SSH async I/O eval: - ssh-async-default-linux.md (#1890): trigger conditions and 5-step rollout to flip the Linux default from sync to async, with the feature/cfg gate and the OC_RSYNC_SSH_ASYNC=0 escape hatch. - ssh-decouple-delta-from-socket-read.md (#1891): split the SSH read thread from the delta applier via a bounded crossbeam-channel queue; MSG_DATA / MSG_INFO ordering preserved, error propagation via a oneshot channel, queue-depth defaults explained. - ssh-explicit-backpressure-controls.md (#1892): user-facing --ssh-max-in-flight-bytes flag and OC_RSYNC_SSH_MAX_IN_FLIGHT_BYTES env var, implemented as a tokio Semaphore at the multiplex writer and receiver-side queue, default 4 MiB, with the max(N, MAX_PAYLOAD_LENGTH) floor that avoids single-frame deadlock. Each doc lists 5-step impl plan plus trigger conditions and ties back to the umbrella eval's recommendation.
Summary
Testing
https://chatgpt.com/codex/tasks/task_e_690698edff4083238da2865b553f516a