Remote Executor Tests üben die Aufteilung zwischen App-Server und Exec-Server, um sicherzustellen, dass Agentfunktionen sowohl in lokalen als auch in entfernten Ausführungsumgebungen funktionieren.
Remote Executor Tests erfordern derzeit einen x86_64 Linux Host. Es gibt zwei Varianten:
- Docker (Linux Exec-Server)
- Wine (Windows Exec-Server)
Test-Fixtures
Einzelne Testfälle müssen sich aktiv für die Ausführung mit einem Remote Executor entscheiden.
codex_core
Verwenden Sie TestCodexBuilder::build_with_auto_env(), um die Remote-Ausführung in Core-Integrationstests zu aktivieren, es sei denn, der Test benötigt eine genauere Kontrolle über seinen Executor.
app-server
Starten Sie den Server mit TestAppServer::new_with_auto_env(), es sei denn, der Test definiert sein eigenes $CODEX_HOME/environments.toml oder benutzerdefinierte Umgebungen zur Laufzeit.
Starten Sie Threads mit TestAppServer::send_thread_start_request_with_auto_env(), wenn Sie den Server mit dem auto_env-Ansatz erstellt haben. Lassen Sie ThreadStartParams.environments weg (lassen Sie es als None), wenn Sie dies tun.
Testüberspringungen
Wenn ein Test in einer bestimmten Remote Executor Konfiguration nicht besteht, können Sie ihn nur in dieser Konfiguration überspringen. Fügen Sie eine Textbegründung für zukünftige Leser hinzu, wenn das ausgewählte Skip-Makro dies unterstützt.
Wählen Sie das Skip-Makro basierend auf der Ursache des Testfehlers:
skip_if_target_windows!: Verhalten des Windows-Ziels.skip_if_wine_exec!: Einschränkungen des Wine-Exec-Runners.skip_if_host_windows!: Einschränkungen des Windows-Hosts.skip_if_remote!: Lokales Testverhalten.skip_if_no_remote_env!: Remote-Testverhalten.
Bevorzugen Sie Tests, die standardmäßig in allen Host-/Zielkonfigurationen ausgeführt werden. Siehe die $path-types Fähigkeit für die häufigsten Änderungen, die erforderlich sind, um Tests kompatibel zu machen.
Docker
Der Docker-Container wird über ./scripts/test-remote-env.sh erstellt und initialisiert. Wenn Sie dieses Skript in Bash einbinden, erhalten Sie auch die Funktion codex_remote_env_cleanup zur Verwendung nach dem Test.
So führen Sie Core-Integrationstests mit einem Docker Remote Executor aus:
bash -c '
set -euo pipefail
unset CODEX_TEST_REMOTE_EXEC_SERVER_URL
source scripts/test-remote-env.sh
trap codex_remote_env_cleanup EXIT
cd codex-rs
just test -p codex-core --test all
'
So führen Sie App-Server-Integrationstests mit einem Docker Remote Executor aus:
bash -c '
set -euo pipefail
unset CODEX_TEST_REMOTE_EXEC_SERVER_URL
source scripts/test-remote-env.sh
trap codex_remote_env_cleanup EXIT
cd codex-rs
just test -p codex-app-server --test all
'
Wine
Diese Tests bauen einen Exec Server für Windows und führen ihn unter Wine aus, während der App Server auf dem Linux Host verbleibt. Die plattformübergreifende Build Abhängigkeit bedeutet, dass sie nur in Bazel ausgeführt werden.
Für Core-Integrationstests:
bazel test //codex-rs/core:core-all-wine-exec-test
Für App-Server-Integrationstests:
bazel test //codex-rs/app-server:app-server-all-wine-exec-test
Devboxes
Sie können eine Devbox verwenden, um diese Tests auszuführen, wenn Sie auf einem macOS Rechner arbeiten.
Sie können Devboxes mit applied_devbox ls auflisten; wählen Sie diejenige mit codex im Namen aus. Verbinden Sie sich mit der Devbox über ssh <devbox_name>. Verwenden Sie dasselbe Checkout von codex in ~/code/codex. Setzen Sie Dateien bei Bedarf zurück. Mehrere Checkouts benötigen mehr Zeit zum Bauen und nehmen mehr Platz in Anspruch. Überprüfen Sie, ob der SHA und die geänderten Dateien zwischen Remote und lokal synchron sind.