From dbf272ced7d6b06d847595f9c213091e540b38fd Mon Sep 17 00:00:00 2001
From: leeguooooo <guoli@zhihu.com>
Date: Sat, 9 May 2026 04:30:20 +0900
Subject: [PATCH] fix(docker): catch parallel-build failures + stop using glob
 in cp
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Two latent bugs in the release pipeline that conspired to ship a stale
linux-x64 binary in 0.27.0-fork.5 (only caught by manually grepping
the embedded version string):

1. build-linux ran x64 and arm64 in parallel and used a single
   `wait $PID1 $PID2` to join them. That command waits for both, but
   its exit code is the LAST waited pid only — so if x64 silently
   broke and arm64 succeeded, the outer script exited 0 and shipped
   whatever was already in /output from the previous release. Now we
   wait on each pid individually and exit 1 on either failure.

2. build-single's cp used `agent-browser*` which globs to BOTH the
   binary and its `.d` dependency file. When two sources are passed,
   cp requires the destination to be a directory. We weren't, so cp
   exited non-zero with "Not a directory" and the build script
   shrugged it off because the next line was `chmod ... || true`.
   Now we resolve a single explicit source path.
---
 docker/docker-compose.yml | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/docker/docker-compose.yml b/docker/docker-compose.yml
index 39e2e40..b03fd79 100644
--- a/docker/docker-compose.yml
+++ b/docker/docker-compose.yml
@@ -25,8 +25,14 @@ services:
         (echo "→ Linux ARM64" && cargo zigbuild --release --target aarch64-unknown-linux-gnu && cp /build/target/aarch64-unknown-linux-gnu/release/agent-browser /output/agent-browser-linux-arm64 && chmod +x /output/agent-browser-linux-arm64 && echo "✓ Linux ARM64 done") &
         PID2=$!
         
-        # Wait for both to complete
-        wait $PID1 $PID2
+        # Wait for both and check exit codes individually — without this
+        # the outer script exits 0 even if one of the parallel builds
+        # failed, silently leaving a stale binary in /output from the
+        # previous release. Caused 0.27.0-fork.5 to ship with a stale
+        # linux-x64 binary at the first publish attempt until caught
+        # manually by checking the embedded version string.
+        wait $PID1 || { echo "✗ Linux x64 build failed"; exit 1; }
+        wait $PID2 || { echo "✗ Linux ARM64 build failed"; exit 1; }
         
         echo ""
         echo "✓ Linux platforms built successfully!"
@@ -67,8 +73,14 @@ services:
       - OUTPUT_NAME=${OUTPUT_NAME:-agent-browser-linux-x64}
     command: |
       -c '
+        set -e
         cargo zigbuild --release --target $TARGET
-        cp /build/target/$TARGET/release/agent-browser* /output/$OUTPUT_NAME
+        # Copy the binary explicitly. The previous `agent-browser*` glob
+        # matched the binary AND its `.d` dependency file, which made cp
+        # treat the destination as a directory and silently failed.
+        SRC="/build/target/$TARGET/release/agent-browser"
+        if [ -f "$SRC.exe" ]; then SRC="$SRC.exe"; fi
+        cp "$SRC" "/output/$OUTPUT_NAME"
         chmod +x /output/$OUTPUT_NAME 2>/dev/null || true
         echo "✓ Built $OUTPUT_NAME"
       '