ci: Run GitHub Actions jobs on Namespace runners

[JPeer264]

This moves all GitHub Actions jobs to Namespace runners. It keeps node_modules, the pnpm store and the Playwright browsers on Namespace cache volumes instead of the GitHub cache, so every job runs pnpm install --frozen-lockfile and there is no dependency cache key anymore.

Runner decisions

Jobs use 3 profiles, sized from the CPU and memory peaks in nsc instance report: -small (2 vCPU, 4 GB) for bots and checks, the default (4 vCPU, 8 GB) for E2E and light jobs, -large (8 vCPU, 16 GB) for build, lint and tests. One profile for all jobs is simpler, but slower or more expensive.

Cache decisions

All build.yml jobs share one cache volume through cache-tag=sentry-javascript, for all branches (last write wins). Alternative: let only develop write to it ("Protect caches from updates").

[JPeer264]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit da69d0e. Configure here.}

[nicohrubec]

nice, did you check the wall time for full ci runs before/after?

[nicohrubec]

q: do we have other profiles available than small/default/large? just wondering if we could tune this further for instance in cases where we have jobs that take a long time but don't necessarily have good parallelism so having more cores doesn't help

[JPeer264]

Yes, those are custom. I created them manually and were already tuned by how much CPU/memory we use.

[nicohrubec]

ah so we can create custom profiles as we see fit or do we need to ask someone to do that for us?

[JPeer264]

exactly.

You can do it yourself, after I add you to the account

[nicohrubec]

that's cool

[JPeer264]

nice, did you check the wall time for full ci runs before/after?

Yes.

Namespace: https://github.com/getsentry/sentry-javascript/actions?query=branch%3Ajp%2Fnamespace-arm64-runners+workflow%3A%22CI%3A+Build+%26+Test%22
vs GHA runners: https://github.com/getsentry/sentry-javascript/actions?query=workflow%3A%22CI%3A+Build+%26+Test%22+branch%3Adevelop

The details of each run, can be viewed in the namespace dashbaord. There is a nice list of when a Job started, when it finished - that's great for optimizing in the future

[nicohrubec]

let's see what it can do 🚤

[sentry-warden]

Untrusted PRs can poison caches reused by secret-bearing CI

This expression gives every pull_request the same -pr cache tag, while merge_group jobs use the non-PR sentry-javascript tag. An untrusted run can alter the shared Playwright cache, then a later optional E2E job can reuse and execute the cached browser with E2E credentials.

Evidence

• build.yml accepts both pull_request and merge_group; this tag expression isolates neither merge-group runs from the main cache nor individual PRs from one another.
• job_build checks out the event commit and runs build commands after mounting the dependency cache. job_browser_playwright_tests uses the same tag, mounts the Playwright cache through install-playwright, and runs code from the checkout.
• install-playwright/action.yml mounts the playwright cache and runs Playwright installation, which downloads only browsers missing from the cache. A PR-controlled test can alter the mounted cache after installation.
• job_optional_e2e_tests uses the same cache-tag scheme, exposes E2E credentials, and installs and runs Playwright; it can therefore execute a browser persisted by another PR run. Merge-group runs also write to the cache used by trusted branch jobs.

Also found at 3 additional locations

• .github/workflows/build.yml:1056-1058
• .github/workflows/build.yml:194-196
• .github/workflows/build.yml:69-71

_{Identified by Warden · security-review · 5UE-MCQ}