Closed Bug 1677471 Opened 4 years ago Closed 3 years ago

Build geckodriver for AArch64 on Mac (Apple Silicon)

Categories

(Testing :: geckodriver, task, P2)

Product:
Testing
Component:
geckodriver
Version:
Default
Platform:
ARM64
macOS
Type:
task

Tracking

(firefox88 fixed)

Status:
RESOLVED FIXED
Milestone:
88 Branch
Tracking Flags:
Tracking Status
firefox88 --- fixed

People

(Reporter: whimboo, Assigned: whimboo)

References

Details

Attachments

(1 file, 1 obsolete file)

Bug 1677471 - [geckodriver] Build binaries for MacOS AArch64.
48 bytes, text/x-phabricator-request
Details | Review

With Apple having released Big Sur there is now a need for Aarch64 support for geckodriver. We should ship support for it with the next release.

Given that we do not ship a DMG bundle we will have to release two different versions of geckodriver on Mac. One for Intel and the other for Aarch64.

For the current status of implementation in Rust see:
https://github.com/rust-lang/rust/issues/73908

Right now there is no Tier1 support for MacOS Aarch64, and as such we also don't have toolchain build jobs.

Given that Rosetta will be perfectly emulating a current x86-64 binary of geckodriver on ARM, there shouldn't be an immediate need to get this support added. Lets revisit in a couple of weeks.

Priority: P2 → P3
No longer blocks: 1668243

As it looks like we will get aarch64 support in Rust 1.49. In bug 1678439 the beta release is used to actually build Firefox for Apple Silicon.

So lets wait for the 1.49 release, and reconsider then.

With bug 1684954 our internal rustc version will be updated to the final 1.49. With that bug fixed we can then check if we want to publish native aarch64 builds.

Depends on: 1684954

There are rumors that Apple might remove Rosetta 2 support in some regions earlier. As developers have seen for the 3rd beta for MacOS 11.3 some strings have been added. If that's true or not, we should be prepared for that and actually ship a ARM64 version of geckodriver.

Also all dependencies are fixed, and our build system has support for it.

Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Priority: P3 → P2
Attachment #9207991 - Attachment is obsolete: true

With the attached patch I get a build error because the linker tries to use arm64 instead of aarch64:
https://treeherder.mozilla.org/logviewer?job_id=332653505&repo=try&lineNumber=588-592

[task 2021-03-10T08:49:54.211Z] error: linking with `cc` failed: exit code: 1
[task 2021-03-10T08:49:54.211Z]   |
[task 2021-03-10T08:49:54.211Z]   = note: "cc" "-arch" "arm64" [..]
[task 2021-03-10T08:49:54.212Z]   = note: cc: error: arm64: No such file or directory
[task 2021-03-10T08:49:54.212Z]           cc: error: unrecognized command line option '-arch'; did you mean '-march='?

Glandium, do you have an idea what's wrong here?

Flags: needinfo?(mh+mozilla)

You need to update taskcluster/scripts/misc/build-geckodriver.sh. See what was done for cbindgen in https://phabricator.services.mozilla.com/D104978

Flags: needinfo?(mh+mozilla)

Thanks! That looks pretty straight forward.

Blocks: 1686110

Joel, is there a way to run wpt (wdspec) tests on a Aarch64 MacOS device yet? We would like to make sure that when shipping the geckodriver binary for M1 is actually working.

Flags: needinfo?(jmaher)

we don't have any machines in production yet- there is a lot of paperwork and right now we are waiting on vpn connection. I didn't plan for wdspec capacity. currently on osx, these take up ~3 hours for a full set of tests. That is a lot and basically every hour of automation ~= 1 machine needed. Is there a reduced set of tests you can run? Maybe opt only, ignore headless, and a subset of the existing tests?

Flags: needinfo?(jmaher) → needinfo?(hskupin)

(In reply to Joel Maher ( :jmaher ) (UTC -0800) from comment #11)

Is there a reduced set of tests you can run? Maybe opt only, ignore headless, and a subset of the existing tests?

Running all wdspec tests shouldn't take 3h. Maybe you are confused with web-platform-tests that contain these tests. When I query mozilla-central I can see:

https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=wdspec%2Cship%2Cmac

So headless takes around 37minutes and non-headless 45minutes. Basically I would be happy with just a having test jobs for mozilla-central for now (maybe even nightly only). And it doesn't matter if it's headless or not. We could take what's faster.

Given that we don't have machines in production yet, I would suggest that we land this patch and have the Aarch64 binary at least build. We could mention Tier-2 support and not putting it on the official release page of geckodriver.

Flags: needinfo?(hskupin) → needinfo?(jmaher)
Pushed by hskupin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ccd0f12b8293
[geckodriver] Build binaries for MacOS AArch64. r=firefox-build-system-reviewers,andi,mhentges,glandium

whimboo, can we run a subset of opt/headless? there is machine reboot and taskcluster overhead as well, per job it starts to add up.

Flags: needinfo?(jmaher) → needinfo?(hskupin)

(In reply to Joel Maher ( :jmaher ) (UTC -0800) from comment #14)

whimboo, can we run a subset of opt/headless? there is machine reboot and taskcluster overhead as well, per job it starts to add up.

I would have to forward this to James. Not sure if running wpt jobs on Taskcluster mozharness support running specific folders.

Sadly we don't have just sanity checks. But whereby what about the Rust unit tests? Would those maybe sufficient for the time being until we have a pool of M1 machines in production?

Flags: needinfo?(hskupin) → needinfo?(james)

wpt tests are not scheduled for M1 nor are rust tests. We have vetted this list of tests with many people, the goal is bare minimum test coverage for the new platform, not minimum test coverage or low test coverage. Just asking for 50 machines in production has added weeks of signatures and meetings.

Sorry I was unclear. wdspec is a subset of wpt, which can be run independently. But I don't know if folder selection will work easily.

Folder selection can work; if you have a list of tests (or a test) that we could use as critical smoketests we have the ability to configure a task that just runs those. But per what jmaher says it sounds like we shouldn't expect much in the short term; nothing more than "geckodriver is able to start and create a session", and even that might be too much right now. Running the first test of a given type incurs all the overhead of creating the test environment specific to that test type, which as jmaher says can be many minutes of machine time and we're highly constrained.

That said I don't think GeckoDriver should have loads of arch-specific code so if we can verify it works at all then it would be surprising (but not impossible!) to see M1 additional specific issues in individual tests (unless they are underlying Gecko issues ofc).

Flags: needinfo?(james)

Ok, then we will use the approach as layed out in comment 12 and ship aarch64 support as tier-2.

https://hg.mozilla.org/mozilla-central/rev/ccd0f12b8293

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox88: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch

Hi Mike, during your review of my patch you offered a quick smoke test of geckodriver on an M1 device. If you find the time we would appreciate your feedback in how it works. As mentioned on Phabricator running the Wdspec tests would be the best way here. To do that you would have to run the following command:

mach wpt --webdriver-binary=path/to/geckodriver testing/web-platform/tests/webdriver/tests/

Thanks a lot!

Flags: needinfo?(mh+mozilla)

It's taking forever, but it works.

Flags: needinfo?(mh+mozilla)

Yes, tests take a long time to run. Thanks a lot for verifying that it works!

Blocks: 1700557
No longer blocks: 1686110
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: