Add support to release aarch64 (arm64) wheels #12183

odidev · 2021-06-09T06:45:38Z

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 · 2021-06-09T16:08:55Z

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:

CI builds and uploads wheels to temporary storage in s3
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 · 2021-06-09T16:19:56Z

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 · 2021-06-17T11:52:31Z

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 · 2021-06-17T16:47:58Z

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 · 2021-10-14T06:23:17Z

Some related work towards this: #13249

mathematicalmichael · 2021-11-02T14:22:14Z

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

Eric-Arellano · 2021-11-02T14:28:15Z

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 · 2021-11-02T21:57:40Z

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 · 2021-11-02T22:02:40Z

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 · 2021-11-02T23:15:59Z

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

benjyw · 2021-11-02T23:16:14Z

@mathematicalmichael Is this something you have any experience with?

mathematicalmichael · 2021-11-03T00:55:28Z

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 · 2021-12-06T20:42:58Z

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

mathematicalmichael · 2021-12-30T07:10:40Z

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 · 2021-12-30T17:58:27Z

#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 · 2021-12-30T18:54:14Z

@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 · 2021-12-30T19:19:43Z

@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 · 2021-12-30T19:24:24Z

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 · 2021-12-30T19:29:38Z

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 · 2021-12-30T19:40:37Z

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 · 2021-12-30T19:43:55Z

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 · 2021-12-30T21:01:23Z

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 <mm@clfx.cc>
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 · 2021-12-30T21:08:53Z

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 · 2021-12-30T21:47:20Z

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 · 2022-03-13T20:35:15Z

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 · 2022-03-14T18:57:22Z

@asherf FYI

asherf · 2022-03-16T20:36:38Z

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.

To prepare for #12183.

* Make Pants aware of the Linux ARM architecture This is work towards #12183. Having these changes, it was possible to run Pants from sources on a repository on an aarch64 Linux machine (Nvidia Tegra). [ci skip-build-wheels]

cognifloyd · 2022-08-16T17:44:54Z

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 · 2022-11-24T20:57:32Z

Requested resources here: https://github.com/WorksOnArm/equinix-metal-arm64-cluster/issues/314

benjyw · 2022-11-26T19:48:01Z

This gets all tests passing on aarch64: #17645

stuhood · 2023-01-24T20:39:06Z

Thanks @benjyw!

jriddy · 2023-01-24T20:44:51Z

Awesome! Excited to use this

stuhood mentioned this issue Jun 9, 2021

Distribute an sdist for Pants #10718

Closed

odidev mentioned this issue Sep 14, 2021

Add linux aarch64 wheel build support #12879

Closed

stuhood added the 2022-idea label Jan 19, 2022

Eric-Arellano changed the title ~~Add support to release aarch64 wheels~~ Add support to release aarch64 (arm64) wheels Feb 11, 2022

benjyw assigned asherf Mar 14, 2022

asherf mentioned this issue Mar 21, 2022

[internal] Rename build wheels steps to include architecture #14861

Merged

stuhood pushed a commit that referenced this issue Mar 21, 2022

[internal] Rename build wheels steps to include architecture (#14861)

d001d3e

To prepare for #12183.

achimnol mentioned this issue May 3, 2022

Crash with "Filesystem changed" #15310

Closed

alexey-tereshenkov-oxb mentioned this issue May 19, 2022

[internal] Make Pants aware of the Linux ARM architecture #15536

Merged

stuhood removed the 2022-idea label Aug 19, 2022

stuhood assigned benjyw and unassigned asherf Jan 9, 2023

stuhood closed this as completed Jan 24, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support to release aarch64 (arm64) wheels #12183

Add support to release aarch64 (arm64) wheels #12183

odidev commented Jun 9, 2021

stuhood commented Jun 9, 2021 •

edited

Loading

Eric-Arellano commented Jun 9, 2021 •

edited

Loading

odidev commented Jun 17, 2021

stuhood commented Jun 17, 2021 •

edited

Loading

benjyw commented Oct 14, 2021

mathematicalmichael commented Nov 2, 2021 •

edited

Loading

Eric-Arellano commented Nov 2, 2021

mathematicalmichael commented Nov 2, 2021 •

edited

Loading

mathematicalmichael commented Nov 2, 2021

benjyw commented Nov 2, 2021

benjyw commented Nov 2, 2021

mathematicalmichael commented Nov 3, 2021

yoav-orca commented Dec 6, 2021

mathematicalmichael commented Dec 30, 2021

Eric-Arellano commented Dec 30, 2021

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

Eric-Arellano commented Dec 30, 2021

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

Eric-Arellano commented Dec 30, 2021

mathematicalmichael commented Dec 30, 2021

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

jriddy commented Mar 13, 2022

benjyw commented Mar 14, 2022

asherf commented Mar 16, 2022

cognifloyd commented Aug 16, 2022

benjyw commented Nov 24, 2022

benjyw commented Nov 26, 2022

stuhood commented Jan 24, 2023

jriddy commented Jan 24, 2023

Add support to release aarch64 (arm64) wheels #12183

Add support to release aarch64 (arm64) wheels #12183

Comments

odidev commented Jun 9, 2021

Problem

Resolution

stuhood commented Jun 9, 2021 • edited Loading

Eric-Arellano commented Jun 9, 2021 • edited Loading

odidev commented Jun 17, 2021

stuhood commented Jun 17, 2021 • edited Loading

benjyw commented Oct 14, 2021

mathematicalmichael commented Nov 2, 2021 • edited Loading

Eric-Arellano commented Nov 2, 2021

mathematicalmichael commented Nov 2, 2021 • edited Loading

mathematicalmichael commented Nov 2, 2021

benjyw commented Nov 2, 2021

benjyw commented Nov 2, 2021

mathematicalmichael commented Nov 3, 2021

yoav-orca commented Dec 6, 2021

mathematicalmichael commented Dec 30, 2021

Eric-Arellano commented Dec 30, 2021

mathematicalmichael commented Dec 30, 2021 • edited Loading

Eric-Arellano commented Dec 30, 2021

mathematicalmichael commented Dec 30, 2021 • edited Loading

Eric-Arellano commented Dec 30, 2021

mathematicalmichael commented Dec 30, 2021

mathematicalmichael commented Dec 30, 2021 • edited Loading

mathematicalmichael commented Dec 30, 2021 • edited Loading

mathematicalmichael commented Dec 30, 2021 • edited Loading

mathematicalmichael commented Dec 30, 2021 • edited Loading

jriddy commented Mar 13, 2022

benjyw commented Mar 14, 2022

asherf commented Mar 16, 2022

cognifloyd commented Aug 16, 2022

benjyw commented Nov 24, 2022

benjyw commented Nov 26, 2022

stuhood commented Jan 24, 2023

jriddy commented Jan 24, 2023

stuhood commented Jun 9, 2021 •

edited

Loading

Eric-Arellano commented Jun 9, 2021 •

edited

Loading

stuhood commented Jun 17, 2021 •

edited

Loading

mathematicalmichael commented Nov 2, 2021 •

edited

Loading

mathematicalmichael commented Nov 2, 2021 •

edited

Loading

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

mathematicalmichael commented Dec 30, 2021 •

edited

Loading

mathematicalmichael commented Dec 30, 2021 •

edited

Loading