fix(ci): add swap and limit CPU cores to prevent arm64 runner OOM

[xmfcx]

• Closes: fix(ci): limit CPU cores in Docker build to prevent ARM64 runner OOM #6956

Changes

1. Add 8 GB swapfile for arm64 health-check builds -- the arm64 runner (4 vCPU / 16 GB RAM) intermittently OOM-kills during heavy C++ compilation. Adding swap increases virtual memory from ~18 GB to ~26 GB, providing headroom for transient memory spikes.

2. Use taskset to restrict colcon build to nproc - 1 cores -- reserves one core for OS/Docker/BuildKit overhead. Under taskset, nproc returns 3, so colcon builds 3 packages in parallel instead of 4.

3. Print runner info (CPU, memory, swap, disk) before the build for easier debugging.

Why

The docker-build (main-arm64) job intermittently fails because colcon build defaults to using all available cores. With multiple packages compiling in parallel, each spawning multiple cmake compile jobs, the runner exceeds its memory budget and loses communication with the server.

taskset alone was insufficient (see #6956 comment) because it only limits CPU affinity, not memory. 9 concurrent compiler processes (3 packages x 3 jobs) can still exceed 16 GB. The additional swap provides the extra headroom needed.

If this is still not enough, the next step is CMAKE_BUILD_PARALLEL_LEVEL to directly limit per-package compile jobs.

Test plan

• Verify docker-build (main-arm64) health-check job passes without runner communication loss
• Verify other matrix entries (main, nightly) are unaffected
• Verify runner info step prints CPU/memory/swap/disk stats

[github-actions]

Thank you for contributing to the Autoware project!

🚧 If your pull request is in progress, switch it to draft mode.

Please ensure:

• You've checked our contribution guidelines.
• Your PR follows our pull request guidelines.
• All required CI checks pass before marking the PR ready for review.

[xmfcx]

• update: fix(ci): limit CPU cores in Docker build to prevent ARM64 runner OOM #6956 (comment)

Now testing with the added 8G swap.

[mitsudome-r]

Looks good to me.

It might be more useful if we could add an argument for workflow dispatch to enable limiting the number of cores further whenever CI fails due to out of resource. But that doesn't have to be done in this PR.

[xmfcx]

It took 3 hours but at least it passed.

My guess is that because it utilizes swap more, it becomes more inefficient.

Maybe CMAKE_BUILD_PARALLEL_LEVEL could also be used to make it use less memory by limiting parallel tasks per package build too. But it complicates things even more. Let's merge for now.

It might be more useful if we could add an argument for workflow dispatch to enable limiting the number of cores further whenever CI fails due to out of resource. But that doesn't have to be done in this PR.

The health-check is a required check and runs on: pull_request. So even if we ran it with different params through workflow_dispatch, we would have to override things from this PR to merge. I tried to have a non-intervention way of fixing the issue.