Add M1 Mac driver for GoogleChrome 95.0.4638.17

[MadsThy]

Add M1 Mac driver for GoogleChrome 95.0.4638.17

[kennethknudsen]

1+

i also need this addition to run test on my M1 mini 🙏🏻

[sephiroth-j]

I will have to check if the new "bit" could cause any problems.

ps. What is the value of System.getProperty("sun.arch.data.model") on M1 Mac?

[MadsThy]

Hey @sephiroth-j :) Thanks for checking it out!

I just made a simple java program and got the property. It's just plain and simple this:

os.arch=aarch64 sun.arch.data.model=64

and when i try to run my gradle install of the chrome driver 95.0.4638.17 it gives me back that there was no driver found for chromedriver with platform=mac, and bit=arm64 or 32.

This is what lead me to go to Googles repo and check out that they had the driver i have added here :) Hope that clarifies things.

[sephiroth-j]

Thanks for checking the sys props, @MadsThy .

I think the plugin needs to support this kind of bit first (or something similar) before adding the new drivers to the repository. As of now, the plugin would detect platform=mac and bit=64. It would then download the regular chromedriver_mac64.zip - which would be wrong. It therefore needs another attribute to detect the "right" driver variant. The os.arch / cpu architecture would be good. It would be a new property of the driver object defaulting to "x86" if not set. CPU arch + platform + 64bit = better driver selection.

It may be Mac on ARM64 now, but there was/is also Windows on IA64 or ARM64.

[MadsThy]

Hey @sephiroth-j

I see what you mean, but are you sure this will be an issue? There is the "platform" part of the instance, so i would not assume people use this repo wrongly :)

For my sake, in the project we are using this repo-file in, i get this message

This leads me to believe that it will not be a problem, since it should not target Windows machines running ARM64.

It is part of this Gradle package: https://github.com/erdi/webdriver-binaries-gradle-plugin/blob/master/README.md

Are you sure others will get a problem out of this? Surely they will have to consume this json file correctly on their end?

[sephiroth-j]

Currently the webdriverextensions-maven-plugin does not care about the CPU architecture and therefore recognizes bit=64 for ARM64. And it is technically incorrect to use bit-ness (32 or 64) for other values like CPU architecture.

The webdriver-binaries-gradle-plugin uses the CPU architecture and somehow maps it to the bit property of the driver objects in the repository file. Therefore, it detects bit=arm64 on your Mac with ARM64 and would therefore download the arm64 variant of the driver.

So before adding drivers for CPU architectures other than x86 to the official repository file, I would like to make sure that this works for users of the webdriverextensions-maven-plugin.

[MadsThy]

@sephiroth-j I will fork the plugin repo then, and change the hardcoded URL to be one that i already forked for this PR, and then see if it works for me here on the M1.

I am unsure if there is anything else you'd like me to do. Could you elaborate if you have something you'd want before accepting this PR?

[MadsThy]

@sephiroth-j I have now tested out modifying the webdriver-binaries-gradle-plugin to make it get from my own repo-3.0.json file with the parameters i have put in this PR. It works :) The file gets downloaded for the project, but i am currently trying to work out another bug that shows up after it is downloaded. Will keep you updated.

[sievemaker]

@sephiroth-j @MadsThy it would be great if that could be merged :/

[MadsThy]

@LRzeszotarski I agree, but sadly I'm not the repo maintainer 😅

[sievemaker]

@MadsThy I managed to download the version for M1 with by defining (where package.json is extended version of https://github.com/webdriverextensions/webdriverextensions-maven-plugin-repository/blob/master/repository-3.0.json)

    driverUrlsConfiguration = resources.text.fromFile('package.json')
    chromedriver {
        version = chromeDriverVersion
        architecture = 'ARM64'
    }

and the right driver seems to be downloaded, but when I start my tests I still got...

Execution failed for task ':configureChromeDriverBinary'.
> java.lang.reflect.InvocationTargetException

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

Do you have any idea what can cause that?

[MadsThy]

@LRzeszotarski Unfortunately I no longer work for the company where I had the issue, and thus can't comment on the errors I saw back then :( I hope you figure it out and we get this PR merged eventually though!

[pschulz]

Hi all,

just to summarize, @sephiroth-j is concerned that using the "bit" property for anything else than a 32 or 64 could cause any problems, hence nobody merged any of the propsed "arm64" bit values yet.

Wouldn't it make sense to introduce a new property like "arch" instead that could take all of the different variants as they are? It can stay backward compatible as the current bit behavior keeps untouched. So then you could also perfectly have different entries for IA64, aarch64 and ARM64 in parallel, even though they could point to the same binary.

[sephiroth-j]

@pschulz Right, that's what I said and that's what I started working on. There is no release date yet, but it will be this year unless something comes up. I still have to write some tests, and when I am satisfied with them, I will release a SNAPSHOT version and do some field tests before there will be a final release version.

[sephiroth-j]

Please test the version 3.4.0-SNAPSHOT of the plugin that supports Mac on M1. See https://github.com/webdriverextensions/webdriverextensions-maven-plugin/issues/65#issuecomment-1264670358 for more information and leave a comment there if it works or not.

[sephiroth-j]

closed in favor of #111 which contains the new "arch" property