1fe89de576
## Why We want to exercise a linux app-server against a windows exec-server without having to repeat every test case. This approach has slight precedent in the remote docker test setup. ## What Run the shared `codex-core` integration suite against Windows exec-server behavior from Linux. This makes cross-OS path and shell regressions visible while keeping unsupported cases owned by individual tests. - Add `local`, `docker`, and `wine-exec` test environment selection with legacy Docker compatibility. - Extend `codex_rust_crate` to generate a sharded Wine-exec variant using a cross-built Windows server and pinned Bazel Wine/PowerShell runtimes. - Teach remote-aware helpers about Windows paths and track temporary incompatibilities with source-local `skip_if_wine_exec!` calls and follow-up reasons.
893 B
name, description
| name | description |
|---|---|
| remote-tests | How to run tests using remote executor. |
Some Codex integration tests select local, docker, or wine-exec through
CODEX_TEST_ENVIRONMENT. The legacy CODEX_TEST_REMOTE_ENV=<container> still
selects Docker; otherwise execution is local.
Docker container is built and initialized via ./scripts/test-remote-env.sh
On x86-64 Linux, run Wine exec with
bazel test //codex-rs/core:core-all-wine-exec-test --test_output=errors.
Temporary blockers belong beside the test in skip_if_wine_exec! calls.
You can list devboxes via applied_devbox ls, pick the one with codex in the name.
Connect to devbox via ssh <devbox_name>.
Reuse the same checkout of codex in ~/code/codex. Reset files if needed. Multiple checkouts take longer to build and take up more space.
Check whether the SHA and modified files are in sync between remote and local.