#!/usr/bin/env bash
#
# 发布 Linux 包：**构建成功才打包**。
#
# 为什么要有这个脚本（而不是在命令行里手打两步）：
#   `npm run build 2>&1 | tail -4 && electron-builder …` 这种写法里，
#   pipeline 的退出码取的是**最后一个命令**（`tail`）的 —— 构建失败、`&&` 照走、
#   打包器拿**旧的 dist** 打了个新包，而所有判据都是绿的
#   （vitest 绿、packaging 绿：它比的是 dist 与包，两边都是旧的，自然一致）。
#   那是真实发生过的一次（见 test/build-stamp.test.mjs 与计划文档 §7.20）。
#
# 两道门，互不替代：
#   - `set -euo pipefail` + 顺序调用：**构建失败就不打包**（喂退出码，真正的门）；
#   - `dist` 比 `src` 新那条判据：**探测器**，抓"src 改了而产物没跟上"。
#     注意它抓不到"构建失败但已经碰过 dist"—— 实测过，那种情况它是绿的。
#
# 构建只有一条路：走 `npm run build`（= `gen:bg` + `vite build`）。
# 这里原来写的是裸 `vite build`，那会**跳过 gen:bg**（背景接管用的 CSS 生成步骤），
# 于是生成物缺失/过期时打包器照打不误。
#
# 两个环境变量是给判据用的接缝（test/packaging.test.mjs 会注入一个失败的构建，
# 断言它**真的会停下**且不进入打包）：
#   AGENTMAIL_BUILD_CMD / AGENTMAIL_PACK_CMD
set -euo pipefail

BUILD_CMD="${AGENTMAIL_BUILD_CMD:-npm run build}"
PACK_CMD="${AGENTMAIL_PACK_CMD:-npx electron-builder --linux -c.electronDownload.isVerifyChecksum=false}"

mkdir -p .tmp
export TMPDIR="${TMPDIR:-$PWD/.tmp/${DSH_SESSION_ID:-$(id -un)-$$}}"
mkdir -p "$TMPDIR"

echo "[release] 构建：$BUILD_CMD"
bash -c "$BUILD_CMD"

echo "[release] 打包：$PACK_CMD"
bash -c "$PACK_CMD"

echo "[release] 完成：dist 与安装包同批（这一句只在两步都成功后才出现）"