Add support to release aarch64 (arm64) wheels

[odidev]

Problem

On AArch64, ‘pip install pantsbuild-pants’ gives an error. Also no ‘setup.py’ file is available to install/build it through source code. It requires the user to have the development environment installed on his system for building wheels.

Resolution

On aarch64, ‘pip install pantsbuild-pants’ should download the wheels from pypi

@Eric-Arellano, Please let me know your interest in releasing aarch64 wheels. I can help with this.

[stuhood]

We would be interested! The last time we looked at this was before migrating to Github Actions... now that we've done that, there is less cruft standing in the way.

Releases are built as a two step process where:

1. CI builds and uploads wheels to temporary storage in s3
2. a releaser downloads from the temporary storage and publishes with twine

Our Github actions config is generated:

pants/.github/workflows/test.yaml

Lines 1 to 3 in 3adc0e0

	# GENERATED, DO NOT EDIT!
	# To change, edit `build-support/bin/generate_github_workflows.py` and run:
	# ./pants run build-support/bin/generate_github_workflows.py

---

Assistance in updating either of those steps would be very appreciated.

[Eric-Arellano]

That'd be great! For distributing as an sdist, I wonder if we want to use maturin, which is the "modern" way to package PyO3 and Rust-CPython applications - it supersedes rust-setuptools. https://github.com/PyO3/maturin. But the tricky thing is we use Pants to handle packaging, and we'd need to have a plugin for maturin, which is doable but also non-trivial.

The simpler implementation might be to distribute prebuilt wheels. Specifically, you could use the Manylinux docker image like we currently do for x86:

pants/build-support/bin/generate_github_workflows.py

Line 418 in 3adc0e0

"container": "quay.io/pypa/manylinux2014_x86_64:latest",

You could add a new job build_wheels_aarch64 that is almost identical to the current job. (Use Python to deduplicate)

This also needs to be updated, how we rename the wheels to be manylinux. Note that we really should be using auditwheel, but we haven't.

pants/build-support/bin/release_helper.py

Lines 709 to 716 in 3adc0e0

	def reversion_prebuilt_wheels() -> None:
	# First, rewrite to manylinux. See https://www.python.org/dev/peps/pep-0599/. We build on
	# Centos7, so use manylinux2014.
	source_platform = "linux_x86_64"
	dest_platform = "manylinux2014_x86_64"
	unstable_wheel_dir = CONSTANTS.deploy_pants_wheel_dir / CONSTANTS.pants_unstable_version
	for whl in unstable_wheel_dir.glob(f"*{source_platform}.whl"):
	whl.rename(str(whl).replace(source_platform, dest_platform))

Update this to be 9:

https://github.com/pantsbuild/pants/blob/3adc0e05912019b5c67959ce54422477cbf47eb9/build-support/bin/release_helper.py#L842-847

And this to have the appropriate platform:

pants/build-support/bin/release_helper.py

Line 564 in 3adc0e0

for plat in ("linux_x86_64", "macosx_10.15_x86_64")

Although @stuhood prebuildling the wheel adds to our CI time even more - thoughts? I suspect that's a wordy worthy tradeoff to make the experience better for users.

[odidev]

I am trying to build the aarch64 wheels but while building native engine I’m facing an error. Please check line number 815 of the following logs:

https://github.com/odidev/pants/runs/2840525747?check_suite_focus=true

Could you please have a look at the error and share your suggestions for the same?

[stuhood]

I am trying to build the aarch64 wheels but while building native engine I’m facing an error. Please check line number 815 of the following logs:

https://github.com/odidev/pants/runs/2840525747?check_suite_focus=true

Hm... that is surprising! If that error isn't a false positive, it could be that the virtual machines that Github Actions use for aarch64 builds have less virtual memory available?

If so, you might try lowering the [GLOBAL] local_store_*_max_size_bytes settings: in particular, local_store_files_max_size_bytes: https://www.pantsbuild.org/docs/reference-global#section-local-store-files-max-size-bytes. LMDB will try to MMAP the sum of those values, and lowering them in the aarch64 shard might get you around that.

[benjyw]

Some related work towards this: #13249

[mathematicalmichael]

docs told me to comment my +1 for interest in using pants on arm64 (raspi + m1 mac building ubuntu containers).

[Eric-Arellano]

Hey @mathematicalmichael , thanks for commenting! M1s are supported https://blog.pantsbuild.org/how-we-added-apple-silicon-support-to-pants/. Is that working for you?

[mathematicalmichael]

Thank you! I have not yet tried it on my m1 but I do all my development in docker, even there. If I were building atop an ubuntu image (think that pulls in aarch64?) using that machine, could pants work in that environment (eventually, without any workarounds)?

[mathematicalmichael]

Re: the blog post

Have you considered setting up a github actions self-hosted runner on the m1 being used for the deployments? Can kind of get the best of both worlds: abuse github actions on a currently unsupported architecture, take the human out of the loop in place of a server running on their machine listening for jobs.

[benjyw]

Funny you should mention that! Yes, it was discussed recently that we might buy a Mac Mini for that purpose.

[benjyw]

@mathematicalmichael Is this something you have any experience with?

[mathematicalmichael]

not on the m1 specifically but I set up the self-hosted runner on an EC2 instance recently and it was pretty easy.

I don't have github enterprise except through work so it's not something I can play around with (my m1 is a personal machine).

https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#supported-architectures-and-operating-systems-for-self-hosted-runners implies this combo seem currently unsupported though. but it does say arm64 has linux support so I would guess an arm-native docker container on m1 will work?

[yoav-orca]

We are also planning on expanding to graviton in the near future and would appreciate wheels for arm64 Linux as well

[mathematicalmichael]

update on my above question: arm-native docker container on m1 will not work as of now

I ran ./pants package src/python/pants:pants-packagedwith docker image of python:3.9.9-bullseye and wasn't able to compile myself a wheel to use. If I succeed, my current plan is to publish images for different python versions so I can reach for them when developing since the wheels aren't available in pypi. Hopefully that may be of use to you in publishing them somehow, happy to help with that effort if I can be of use (I know its an esoteric ask).

Here is a cleaned up dockerfile (can find it printed at bottom of stacktrace too)

FROM docker.io/python:3.9.9-bullseye
RUN cd /tmp/ && curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs -o install.sh && sh install.sh -y
RUN . ~/.cargo/env && \
    cd /tmp/ && git clone --depth 1 \
         --branch release_2.8.0 https://github.com/pantsbuild/pants && \
     cd pants && ./pants package src/python/pants:pants-packaged
RUN pip install /tmp/pants/dist/pants*.whl

stacktrace:

#6 326.1    Compiling process_execution v0.0.1 (/tmp/pants/src/rust/engine/process_execution)
#6 557.5     Finished release [optimized + debuginfo] target(s) in 8m 43s
#6 559.5 thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "Found unknown system/arch name pair Linux aarch64"', process_execution/src/local.rs:66:37
#6 559.5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
#6 559.6 Traceback (most recent call last):
#6 559.6   File "/tmp/pants/src/python/pants/bin/pants_loader.py", line 119, in <module>
#6 559.6     main()
#6 559.6   File "/tmp/pants/src/python/pants/bin/pants_loader.py", line 115, in main
#6 559.6     PantsLoader.main()
#6 559.6   File "/tmp/pants/src/python/pants/bin/pants_loader.py", line 109, in main
#6 559.6     cls.run_alternate_entrypoint(entrypoint)
#6 559.6   File "/tmp/pants/src/python/pants/bin/pants_loader.py", line 85, in run_alternate_entrypoint
#6 559.6     entrypoint_fn()
#6 559.6   File "/tmp/pants/src/python/pants/pantsd/pants_daemon.py", line 211, in launch_new_pantsd_instance
#6 559.6     daemon = PantsDaemon.create(options_bootstrapper)
#6 559.6   File "/tmp/pants/src/python/pants/pantsd/pants_daemon.py", line 57, in create
#6 559.6     core = PantsDaemonCore(options_bootstrapper, executor, cls._setup_services)
#6 559.6   File "/tmp/pants/src/python/pants/pantsd/pants_daemon_core.py", line 51, in __init__
#6 559.6     self._options_initializer = OptionsInitializer(options_bootstrapper, executor)
#6 559.6   File "/tmp/pants/src/python/pants/init/options_initializer.py", line 101, in __init__
#6 559.6     self._bootstrap_scheduler = create_bootstrap_scheduler(options_bootstrapper, executor)
#6 559.6   File "/tmp/pants/src/python/pants/init/options_initializer.py", line 74, in create_bootstrap_scheduler
#6 559.6     EngineInitializer.setup_graph(
#6 559.6   File "/tmp/pants/src/python/pants/init/engine_initializer.py", line 181, in setup_graph
#6 559.6     return EngineInitializer.setup_graph_extended(
#6 559.6   File "/tmp/pants/src/python/pants/init/engine_initializer.py", line 285, in setup_graph_extended
#6 559.6     scheduler = Scheduler(
#6 559.6   File "/tmp/pants/src/python/pants/engine/internals/scheduler.py", line 216, in __init__
#6 559.6     self._py_scheduler = native_engine.scheduler_create(
#6 559.6 SystemError: Rust panic
#6 564.0 06:38:49.70 [INFO] waiting for pantsd to start...
#6 569.0 06:38:54.69 [INFO] waiting for pantsd to start...
#6 573.9 06:38:59.66 [INFO] waiting for pantsd to start...
#6 579.0 06:39:04.72 [INFO] waiting for pantsd to start...
#6 583.9 06:39:09.67 [INFO] waiting for pantsd to start...
#6 589.0 06:39:14.73 [INFO] waiting for pantsd to start...
#6 594.0 06:39:19.71 [INFO] waiting for pantsd to start...
#6 598.9 06:39:24.67 [INFO] waiting for pantsd to start...
#6 604.0 06:39:29.74 [INFO] waiting for pantsd to start...
#6 609.0 06:39:34.71 [INFO] waiting for pantsd to start...
#6 614.0 06:39:39.70 [INFO] waiting for pantsd to start...
#6 618.9 Traceback (most recent call last):
#6 618.9   File "/tmp/pants/src/python/pants/bin/pants_loader.py", line 119, in <module>
#6 618.9     main()
#6 618.9   File "/tmp/pants/src/python/pants/bin/pants_loader.py", line 115, in main
#6 618.9     PantsLoader.main()
#6 618.9   File "/tmp/pants/src/python/pants/bin/pants_loader.py", line 111, in main
#6 618.9     cls.run_default_entrypoint()
#6 618.9   File "/tmp/pants/src/python/pants/bin/pants_loader.py", line 93, in run_default_entrypoint
#6 618.9     exit_code = runner.run(start_time)
#6 618.9   File "/tmp/pants/src/python/pants/bin/pants_runner.py", line 86, in run
#6 618.9     return remote_runner.run()
#6 618.9   File "/tmp/pants/src/python/pants/bin/remote_pants_runner.py", line 115, in run
#6 618.9     pantsd_handle = self._client.maybe_launch()
#6 618.9   File "/tmp/pants/src/python/pants/pantsd/pants_daemon_client.py", line 38, in maybe_launch
#6 619.0     return self._launch()
#6 619.0   File "/tmp/pants/src/python/pants/pantsd/pants_daemon_client.py", line 62, in _launch
#6 619.0     pantsd_pid = self.await_pid(60)
#6 619.0   File "/tmp/pants/src/python/pants/pantsd/process_manager.py", line 309, in await_pid
#6 619.0     self.await_metadata_by_name(
#6 619.0   File "/tmp/pants/src/python/pants/pantsd/process_manager.py", line 230, in await_metadata_by_name
#6 619.0     self._wait_for_file(file_path, ongoing_msg, completed_msg, timeout=timeout)
#6 619.0   File "/tmp/pants/src/python/pants/pantsd/process_manager.py", line 176, in _wait_for_file
#6 619.0     return cls._deadline_until(file_waiter, ongoing_msg, completed_msg, timeout=timeout)
#6 619.0   File "/tmp/pants/src/python/pants/pantsd/process_manager.py", line 148, in _deadline_until
#6 619.0     raise cls.Timeout(
#6 619.0 pants.pantsd.process_manager.ProcessManager.Timeout: exceeded timeout of 60 seconds while waiting for pantsd to start
------
executor failed running [/bin/sh -c . ~/.cargo/env &&     cd /tmp/ && git clone --depth 1 --branch release_2.8.0 https://github.com/pantsbuild/pants && cd pants &&     ./pants package src/python/pants:pants-packaged]: exit code: 1
eirene:pants mm$ cat Dockerfile 
FROM docker.io/python:3.9.9-bullseye
RUN cd /tmp/ && curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs -o install.sh && sh install.sh -y
RUN . ~/.cargo/env && \
    cd /tmp/ && git clone --depth 1 --branch release_2.8.0 https://github.com/pantsbuild/pants && cd pants && \
    ./pants package src/python/pants:pants-packaged
RUN pip install /tmp/pants/dist/pants*.whl

I see wheels published for old versions, so at some point this combination of pants on aarch64 seems to have been supported (or the wheels were just published without annotations that would tell pip otherwise?). I took a look at the files in the error messages and wasn't able to make sense of what changes I might have to make to get it to work.

I would very much appreciate help with this as I tend to run my development workflows in docker images and was planning to sandbox pants in a docker container, so for me personally adoption on the M1 is dependent on aarch64 wheels. Thank you kindly in advance for taking the time to read through this message.

[Eric-Arellano]

#6 559.5 thread '' panicked at 'called Result::unwrap() on an Err value: "Found unknown system/arch name pair Linux aarch64"', process_execution/src/local.rs:66:37

Thanks, @mathematicalmichael . It looks like our Rust code is failing to run on Linux Arm64 because of this line:

pants/src/rust/engine/process_execution/src/local.rs

Line 66 in 8cd274e

platform: Platform::current().unwrap(),

We only define these as valid "platforms":

pants/src/rust/engine/process_execution/src/lib.rs

Lines 73 to 77 in 8cd274e

	pub enum Platform {
	Macos_x86_64,
	Macos_arm64,
	Linux_x86_64,
	}

So it looks like we indeed do need to do some work on Pants's engine itself to allow you to run on Arm64.

Some of the maintainers will be doing planning soon for what we want to contribute in January. Especially with Gravitron + that this is our most upvoted issue now, I'd personally like to try to allocate a few days to unblocking Arm64.

[mathematicalmichael]

@Eric-Arellano thank you for pointing me to those lines! I very much appreciate that. Perhaps this is a dumb question but ... if I just added an extra line to that lib.rs file, would it not just work? (I guess I'll find out eventually if I keep my eyes on future PRs). EDIT: trying my hand at it.

Like, all the rust libs are available, I guess I just don't know exactly how pants works under the hood (I'm only passively familiar with rust) but I would have expected that the Macos_arm64 build would be compatible with Linux_aarch64 if it were not for explicitly defining them as being different. Is that incorrect?

[Eric-Arellano]

@mathematicalmichael contributions definitely welcomed! See #12367 for how MacOS ARM64 support was added by @chrisjrn. It will look very similar for Linux ARM64.

Check out https://www.pantsbuild.org/docs/contributions-rust for tips on developing in Rust.

[mathematicalmichael]

I tried the most straightforward thing I could think of (copy pasted the linux x86 sections) and it's now on the penultimate build step... fingers crossed.

If this works... would you want a patch for the 2.8.0 release or something for the main branch? I noticed a difference in line numbers with what you linked above (I'm checked out on the release branch).

Thanks for the link! that will help if I encounter an error. (and oh wow that's a lot more changes than I made, guess I wont get my hopes up that this will finish successfully)

[Eric-Arellano]

would you want a patch for the 2.8.0 release or something for the main branch?

We'd start with the main branch. Per our release strategy, we may want to backport it to 2.8 or especially the upcoming 2.9, depending on these criteria: https://www.pantsbuild.org/docs/release-strategy#stable-releases

oh wow that's a lot more changes than I made

I suspect it won't be quite as many changes for Linux :) A lot of what that PR was changing is the generic infrastructure for Platform. It used to only consider OS, and Chris changed it to consider OS + Arch. Now, it should mostly be updating call sites of Platform in both Python + Rust to include Linux ARM64.

The trickier part fwict is getting CI to run ARM64 and to release pre-built wheels with it. But both those things can be done in followups. The first step is simply letting you build with ARM64 locally.

[mathematicalmichael]

would docker buildx + an image along the lines of the one I outlined above (with a step to push the wheel as well) be a feasible strategy? May take too long to compile though (if my times on the raspi are any indication).

The build seems to have failed though. Can't see the stacktrace anymore because stdout is being polluted with this message

(killed the process with htop, based on what I see above, I'm guessing I need to change another rust file). I tried rerunning pants package and just got that message immediately again.

[mathematicalmichael]

if the pants package command is successful, would the wheel exist under dist? just wondering if anything got generated as a result of what I ran (there's no dist folder in the root dir of the repo)

here's what I tried so far:

diff --git a/src/rust/engine/process_execution/src/lib.rs b/src/rust/engine/process_execution/src/lib.rs
index cdf4b67..ee12654 100644
--- a/src/rust/engine/process_execution/src/lib.rs
+++ b/src/rust/engine/process_execution/src/lib.rs
@@ -83,6 +83,7 @@ pub enum Platform {
   Macos_x86_64,
   Macos_arm64,
   Linux_x86_64,
+  Linux_aarch64,
 }
 
 impl Platform {
@@ -97,6 +98,13 @@ impl Platform {
       } if sysname.to_lowercase() == "linux" && machine.to_lowercase() == "x86_64" => {
         Ok(Platform::Linux_x86_64)
       }
+      uname::Info {
+        ref sysname,
+        ref machine,
+        ..
+      } if sysname.to_lowercase() == "linux" && machine.to_lowercase() == "aarch64" => {
+        Ok(Platform::Linux_aarch64)
+      }
       uname::Info {
         ref sysname,
         ref machine,
@@ -127,6 +135,7 @@ impl From<Platform> for String {
   fn from(platform: Platform) -> String {
     match platform {
       Platform::Linux_x86_64 => "linux_x86_64".to_string(),
+      Platform::Linux_aarch64 => "linux_aarch64".to_string(),
       Platform::Macos_arm64 => "macos_arm64".to_string(),
       Platform::Macos_x86_64 => "macos_x86_64".to_string(),
     }
@@ -140,6 +149,7 @@ impl TryFrom<String> for Platform {
       "macos_arm64" => Ok(Platform::Macos_arm64),
       "macos_x86_64" => Ok(Platform::Macos_x86_64),
       "linux_x86_64" => Ok(Platform::Linux_x86_64),
+      "linux_aarch64" => Ok(Platform::Linux_aarch64),
       other => Err(format!(
         "Unknown platform {:?} encountered in parsing",
         other

[mathematicalmichael]

I needed to set --local-store-files-max-size-bytes to 1/10 the default value, but I was able to get further along and package after modifying the code some more.

From 7144f469d2d03e278dc4a66bad883725676c1cb6 Mon Sep 17 00:00:00 2001
From: mm <[email protected]>
Date: Thu, 30 Dec 2021 19:54:10 +0000
Subject: [PATCH] aarch64 patch

---
 src/python/pants/backend/python/util_rules/pex_cli.py |  2 +-
 src/rust/engine/process_execution/src/lib.rs          | 10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/python/pants/backend/python/util_rules/pex_cli.py b/src/python/pants/backend/python/util_rules/pex_cli.py
index 7a67a2b..e6bab1c 100644
--- a/src/python/pants/backend/python/util_rules/pex_cli.py
+++ b/src/python/pants/backend/python/util_rules/pex_cli.py
@@ -54,7 +54,7 @@ class PexBinary(TemplatedExternalTool):
                     "3693575",
                 )
             )
-            for plat in ["macos_arm64", "macos_x86_64", "linux_x86_64"]
+            for plat in ["macos_arm64", "macos_x86_64", "linux_arm64", "linux_x86_64"]
         ]
 
 
diff --git a/src/rust/engine/process_execution/src/lib.rs b/src/rust/engine/process_execution/src/lib.rs
index cdf4b67..d4f4300 100644
--- a/src/rust/engine/process_execution/src/lib.rs
+++ b/src/rust/engine/process_execution/src/lib.rs
@@ -83,6 +83,7 @@ pub enum Platform {
   Macos_x86_64,
   Macos_arm64,
   Linux_x86_64,
+  Linux_arm64,
 }
 
 impl Platform {
@@ -97,6 +98,13 @@ impl Platform {
       } if sysname.to_lowercase() == "linux" && machine.to_lowercase() == "x86_64" => {
         Ok(Platform::Linux_x86_64)
       }
+      uname::Info {
+        ref sysname,
+        ref machine,
+        ..
+      } if sysname.to_lowercase() == "linux" && (machine.to_lowercase() == "arm64"  || machine.to_lowercase() == "aarch64") => {
+        Ok(Platform::Linux_arm64)
+      }
       uname::Info {
         ref sysname,
         ref machine,
@@ -127,6 +135,7 @@ impl From<Platform> for String {
   fn from(platform: Platform) -> String {
     match platform {
       Platform::Linux_x86_64 => "linux_x86_64".to_string(),
+      Platform::Linux_arm64 => "linux_arm64".to_string(),
       Platform::Macos_arm64 => "macos_arm64".to_string(),
       Platform::Macos_x86_64 => "macos_x86_64".to_string(),
     }
@@ -140,6 +149,7 @@ impl TryFrom<String> for Platform {
       "macos_arm64" => Ok(Platform::Macos_arm64),
       "macos_x86_64" => Ok(Platform::Macos_x86_64),
       "linux_x86_64" => Ok(Platform::Linux_x86_64),
+      "linux_arm64" => Ok(Platform::Linux_arm64),
       other => Err(format!(
         "Unknown platform {:?} encountered in parsing",
         other
-- 
2.30.2

I got a wheel in dist/ and was able to install it with pip in the same container.

However, when I tried to start a new project with pants, it again tried to find something to download from pypi instead of using what I had installed and failed. How can I tell it "please use this specific wheel on my filesystem"?

fwiw, I published it here: wget clfx.cc/pantsbuild.pants-2.10.0.dev0-cp39-cp39-linux_aarch64.whl
looks like the version didnt reflect what I thought I was building (2.8.0, but seems like I was on main afterall).
When I changed my pants.toml in a demo project to require 2.10.*, it still tells me it cant find a distribution (guessing because it's just checking pypi).

[mathematicalmichael]

oh, i see. pants that I installed from my wheel is now at /usr/local/bin but when I use a demo project I was trying the syntax with ./pants... subtly different but important distinction.

I needed to be explicit about the pants version matching in pants.toml when using the former installation (the wildcard failed), and still needed to pass --local-store-files-max-size-bytes=25000000000 when calling pants package (as a test). But! I was able to package the demo! (on a raspberry pi running docker, along with some patience).

[mathematicalmichael]

unfortunately moving beyond basic python starts to hurt... I may be able to package, but running anything proves to be a challenge.

yet if I try this...

is this because of how mlflow names its wheels and how pants uses that information?

same thing happened for numpy... and that's about as basic a need as I have. So... pants can be installed, but not particularly useful right now (unless I'm sticking to pure python) and I think I'm at the limit of my knowledge here with respect to how to fix it. Please let me know if I can be of any help with testing in the future.

[jriddy]

Copying some thoughts here from the Slack thread on this before it gets hidden by the pay-us-to-see-your-history algorithm...

The discussion there centered around how to do this in CI. It was decided that a self-hosted GHA runner on a Graviton instance in AWS could do these builds, namely a t4g.medium instance (probably), hosted in the Pantsbuild AWS account.

For inspriation or for a source work, https://github.com/machulav/ec2-github-runner was floated as a possible way to use GHA itself to manage the instance lifecycle, and https://github.com/jonico/github-runner-1 was suggested as a way to build a runner AMI in packer.

I'm currently working on this. The packer examples repo listed there is pretty complicated—for some reason it wants you to create like 3 different images—but it looks promising. If I can get this to work and create a way to reusably create an image, someone with better creds than I can run the image create on the Pantsbuild org. Then we could work on automating the image creating in a follow-up step.

[benjyw]

@asherf FYI

[asherf]

I have a basic workflow working on my fork of pants (it is easier for me to work on this kind of feature in a [ork since I have full control there),once things are ready, they will be upstreamed.
there is a workflow that starts and stops an arm64 ec2 instance.
there is a 'place' in the workflow where the build steps need to be added (currently there is a place holder that logs some platform info): https://github.com/asherf/pants/blob/jerry/.github/workflows/ec2-test.yaml#L43

As you can see in this GHA run: https://github.com/asherf/pants/runs/5576190005?check_suite_focus=true#step:2:6

the do-the-job runs on the ubuntu arm64 box in AWS EC2.

@benjyw FYI
I think this ticket can be handed off to someone so they can build the logic we want to run on that platform.

[cognifloyd]

It looks like these services have ARM compute available:
CircleCI: https://circleci.com/blog/managing-ci-cd-pipelines-with-arm-compute-resource-classes/
Drone: https://blog.drone.io/drone-announces-official-support-for-arm/
Arm+Equinix baremetal for open source: https://github.com/WorksOnArm/equinix-metal-arm64-cluster/

That last one looks like we might be able to use it to run a GitHub actions runner on arm without the hassle of managing the AWS infrastructure.

[benjyw]

Requested resources here: WorksOnArm/equinix-metal-arm64-cluster#314

[benjyw]

This gets all tests passing on aarch64: #17645

[stuhood]

Thanks @benjyw!

[jriddy]

Awesome! Excited to use this