Chrome's user-namespace sandbox is unusable inside the act runner
container — the host kernel's AppArmor profile (Ubuntu 23.10+) blocks
unprivileged user namespaces, so Chrome aborts at the zygote stage
with `No usable sandbox`. Lighthouse never connects to the browser
and the perf gate fails.
`--no-sandbox` is the standard workaround documented by Lighthouse,
Puppeteer, and Playwright for containerised CI. The residual risk is
acceptable: the browser only loads our own freshly built bundle from
http://localhost:4200/ inside an ephemeral self-hosted runner — no
untrusted content reaches the renderer.
`actions/checkout@v4` already runs with `fetch-depth: 0`, which pulls
every branch and tag — origin/<base_ref> is therefore present locally
and the explicit fetch is redundant. The flag value `--depth=0` is
itself invalid (git requires a positive integer), so the step failed
with `fatal: depth 0 is not a positive number` on every PR run.
Three follow-up fixes uncovered by the first end-to-end CI run on the
self-hosted act_runner image:
- Replace `nrwl/nx-set-shas@v4` with a manual shell step. The action
queries the GitHub API to discover the last successful workflow run
and returns 404 on Gitea. The replacement derives NX_BASE/NX_HEAD
from local git history (merge-base with the target branch on
pull_request, HEAD~1 on push to main).
- Pin the `perf` job to `catthehacker/ubuntu:full-22.04` so Lighthouse
CI finds a real Chrome. The default act image (act-22.04) is the
minimal variant and ships without browsers.
- Declare `pnpm.onlyBuiltDependencies` to silence the "Ignored build
scripts" warning and approve only the packages whose post-install
hooks we actually rely on (Nx, Prisma, esbuild, swc, native
watchers/resolvers).
Julien Gautier