Files
codex/codex-rs/app-server/BUILD.bazel
T
Dmitriy Kovalenko 02d78ab053 Add Bazel release staging archives (#51850)
## What changed

- Add `runtime_package` targets for combined, primary, app-server, and Windows helper bundles, plus per-binary release archives.
- Apply release settings automatically and retain unstripped binaries with macOS dSYM or Windows PDB symbols. Require platform-specific symbols and validate that dSYM bundles contain nonempty DWARF data.
- Support a `debug` build mode for faster package smoke builds and configure platform-specific release settings, including native Windows MSVC toolchains.
- Add a composite action that refreshes Cargo workspace metadata, builds the selected archive, and extracts writable files for existing signing and packaging steps.

GitOrigin-RevId: 21109875cde228aaef67b2ba9812b3e4854aee84
2026-10-07 22:11:14 +00:00

37 lines
1.2 KiB
Python

load("//:defs.bzl", "codex_rust_crate")
load("//bazel/rules:runtime_package.bzl", "release_binary")
codex_rust_crate(
name = "app-server",
crate_name = "codex_app_server",
extra_binaries = [
"//codex-rs/bwrap:bwrap",
"//codex-rs/code-mode-host:codex-code-mode-host",
"//codex-rs/rmcp-client:test_stdio_server",
],
extra_binaries_non_windows = [
"//codex-rs/cli:codex",
],
integration_test_timeout = "long",
run_tests_with_wine_exec = True,
test_shard_counts = {
# Note app-server-all-test has a large number of integration tests, so
# even a single shard can be quite slow. When there is a legitimate
# test failure in a shard, it will still get run 3x in total, which
# can cause us to exhaust our CI timeout if the shard happens to run
# long. Using a higher shard count for app-server-all-test should help
# mitigate this risk.
"app-server-all-test": 16,
"app-server-unit-tests": 8,
},
test_tags = ["no-sandbox"],
test_threads = select({
"@platforms//os:macos": 1,
"//conditions:default": 0,
}),
)
release_binary(
binary = ":codex-app-server",
)