[fix](ci) add swap space in deploy workflows to avoid runner OOM kills

[morningman]

What & Why

The Cron Deploy and Manual Deploy And Upload To OSS jobs have been failing intermittently for the past several days (e.g. 30743875275, 30751563874), and went into a consecutive-failure streak on Aug 2.

Diagnosis from the run logs:

• Every failure ends with ##[error]The runner has received a shutdown signal in the middle of the Build step — the runner VM itself is killed, not a build error and not a workflow timeout.
• The same commit (3862366c) both passed and failed repeatedly across Aug 1–2, and the runner image version is identical between passing and failing runs (ubuntu-24.04 / 20260720.247.2), ruling out code or image changes.
• Failures consistently happen during the memory-heaviest phase (en static generation finished, zh-CN webpack build in progress), after several minutes of log silence, and with no JavaScript heap out of memory error — the classic signature of system-level memory exhaustion killing the runner service: the main node process is allowed --max-old-space-size=8192 and the webpack/terser worker processes push the total past the standard runner's 16G physical memory.

Fix

Add an extra 8G swapfile before the Build step in both deploy workflows, so memory spikes spill into swap instead of getting the VM OOM-killed:

• The swapfile is placed on the /mnt data disk (~65G free) instead of the root disk, which the workspace and build output already fill; named swapfile2 because the runner image ships a built-in 4G /mnt/swapfile — total 12G swap after this change.
• free -h / swapon --show output is printed so future failures can be triaged against the memory baseline directly from the logs.

This is a mitigation for the flaky OOM kills. A follow-up improvement worth considering is splitting docusaurus build --locale en --locale zh-CN into two separate invocations so each locale's peak memory is isolated in its own process.

🤖 Generated with Claude Code