fix(ci): resolve cgroup v2 crash by replacing defunct run-buck action…

[arnabnandy7]

Problem

The CI build is failing on every push with a NullPointerException during Buck startup:

Buck encountered an internal error java.lang.NullPointerException at jdk.internal.platform.cgroupv2.CgroupV2Subsystem.getInstance(CgroupV2Subsystem.java:81) at jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:108) ... at com.facebook.buck.util.environment.DefaultExecutionEnvironment.getTotalMemory(...)

Root Cause

The GitHub Actions runner recently upgraded to Ubuntu 24.04, which exclusively uses cgroup v2. The workflow uses the passy/run-buck@v0.1.0 Docker action, which bundles an unmaintained Docker image based on Ubuntu 18.04 + OpenJDK 8. JDK 8's backported cgroup v2 support is buggy — it throws a NullPointerException when Buck tries to query system memory metrics via ManagementFactory.getOperatingSystemMXBean().

Both buck fetch and buck build crash immediately on startup, before any compilation occurs.

Changes

.github/workflows/build.yml

• Replaced passy/run-buck@v0.1.0 (unmaintained, last updated 2019) with inline workflow steps using the thyrlian/android-sdk container image
• Upgraded JDK from 8 to 11 — OpenJDK 11 has proper cgroup v2 support and is compatible with Buck v2020.10.21.01
• Upgraded actions/checkout from v2 to v4 — v2 was triggering Node.js 20 deprecation warnings on the latest runners
• Split the monolithic shell command into discrete steps (Install deps -> Install Buck -> Setup SDK -> Fetch -> Build) for better debuggability and clearer failure attribution

.buckconfig

• Replaced jcenter.bintray.com with Maven Central (repo1.maven.org/maven2) — JCenter was shut down in February 2021, so buck fetch would fail to download dependencies even after the cgroup fix

Testing

• CI build passes on this branch (push-triggered)

[arnabnandy7]

Replacing the defunct action should fix the immediate cgroup v2 crash, but it would be worth making the CI failure mode explicit. A small workflow note or check that prints the detected cgroup mode would help future failures distinguish runner environment issues from SoLoader test failures. If this action owns Buck setup, one smoke test should still prove the restored cache/toolchain path is used rather than silently falling back to a slower full setup.

@hiSandog Thanks for the review! Agreed on both points. I'll add a step to log/detect the cgroup mode explicitly so future failures are easier to trace, and follow up with a smoke test verifying the restored setup actually hits cache/toolchain rather than silently falling back. Will push both in a follow-up commit shortly.

[arnabnandy7]

@michalgr @helfper @shreerag-meta @VladimirMakaev please review