[rust] Add support for Chrome arm64 on Linux

[dennisameling]

🔗 Related Issues

#15801

Follow-up on #16045 which added initial support for Linux arm64 (Firefox-only)

💥 What does this PR do?

Adds support for Chrome and chromedriver Linux arm64 binaries. Version 153 of Chrome for Testing adds support for his platform: https://googlechromelabs.github.io/chrome-for-testing/

⚠️ browser_latest_download_test will fail on Linux arm64 until version 153 of Chrome for Testing has been promoted to stable.

🔧 Implementation Notes

Needed to remove the hard blockers that said that Chrome for Linux arm64 wasn't supported, which is no longer the case now that official support has landed.

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s): Claude Code
  • What was generated: wrote the initial code updates and tests myself, but noticed some code duplication and missing logic to properly check available download URLs, so asked Claude to write the generic find_platform_url() function.
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

Bindings still need to be updated for Linux arm64: #15801 (comment)

🔄 Types of changes

• Cleanup (formatting, renaming)
• New feature (non-breaking change which adds functionality and tests!)

[qodo-code-review]

PR Summary by Qodo

Rust Selenium Manager: enable Chrome/Chromedriver downloads for Linux arm64 (CfT v153+)

✨ Enhancement 🧪 Tests 🕐 20-40 Minutes

AI Description

• Add Chrome/Chromedriver Linux arm64 support via Chrome-for-Testing endpoints.
• Enforce platform-specific minimum version (Linux arm64 requires CfT v153+).
• Update tests to skip only unsupported Edge cases and validate new arm64 behavior.

Diagram

graph TD
  A["selenium-manager CLI"] --> B["ChromeManager"] --> C["Fetch CfT JSON"] --> D{"URL exists for platform & >= min"}
  D -- "yes" --> E["Set browser/driver URL"] --> F["Download + cache"]
  D -- "no" --> G["Unavailable/min-version error"]
  B --> H["Legacy driver URL"] --> F
  H -- "linux-arm64" --> G

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Precompute a platform->url map for each downloads list

• ➕ Avoid repeated linear scans when selecting platform URLs
• ➕ Makes missing-platform handling explicit at the data-structure boundary
• ➖ More allocations/boilerplate for small lists
• ➖ Less idiomatic than a simple iterator for current usage

2. Centralize CfT "platform availability" filtering in a shared helper for browser+driver

• ➕ Reduces duplication between browser and driver version filtering rules
• ➕ Easier to maintain if CfT schemas/fields change
• ➖ Requires more refactoring across managers and test updates
• ➖ May obscure the different error semantics for browser vs driver

Recommendation: Current approach (a small find_platform_url() helper + filtering versions by URL availability) is a good balance of correctness and minimal change. The main value is the behavioral fix: selecting the newest usable version for the current platform instead of selecting a version and failing later. Consider the platform->url map only if this pattern spreads further or performance becomes a concern.

Files changed (9) +142 / -111

Enhancement (1) +89 / -65

chrome.rsEnable CfT linux-arm64 downloads with platform URL selection and min-version gating +89/-65

Enable CfT linux-arm64 downloads with platform URL selection and min-version gating

• Adds Linux arm64 support for Chrome/Chromedriver by returning the "linux-arm64" platform label and removing the previous hard blocker. Introduces 'find_platform_url()' and filters known-good versions by platform URL availability so the newest usable version wins. Applies a higher minimum (v153) for Linux arm64 downloads and improves error handling when no platform URL exists.

rust/src/chrome.rs

Tests (8) +53 / -46

browser_download_tests.rsAdjust download tests for Linux arm64 Chrome availability and Edge skips +9/-10

Adjust download tests for Linux arm64 Chrome availability and Edge skips

• Uses 'is_linux_arm64()' helper for skip logic instead of directly reading 'ARCH'. Adds a Chrome v153 download case and updates skip messaging/conditions to reflect that Chrome arm64 binaries start at v153 and Edge remains unsupported.

rust/tests/browser_download_tests.rs

browser_tests.rsAdd Chrome/Chromedriver 153 coverage and replace unsupported-chrome test with min-version test +35/-14

Add Chrome/Chromedriver 153 coverage and replace unsupported-chrome test with min-version test

• Adds a 153.x Chrome/Chromedriver test case and refines Linux arm64 skip conditions (skip Edge always; skip Chrome only when requesting <153). Removes the prior test asserting Chrome was unsupported on Linux arm64 and adds a CLI-level test asserting proper failure below the min version.

rust/tests/browser_tests.rs

cache_tests.rsRun cache tests on Linux arm64 as well +0/-1

Run cache tests on Linux arm64 as well

• Removes the cfg-based exclusion that previously skipped cache tests on linux/aarch64, allowing the cache behavior to be validated on Linux arm64 too.

rust/tests/cache_tests.rs

cache_unit_tests.rsRemove unused SeleniumManager import +0/-1

Remove unused SeleniumManager import

• Cleans up an unused import to keep the unit test module minimal and warning-free.

rust/tests/cache_unit_tests.rs

config_tests.rsRefine config test skips to only exclude Edge on Linux arm64 +2/-3

Refine config test skips to only exclude Edge on Linux arm64

• Switches to 'is_linux_arm64()' and narrows skip logic so only Edge is skipped on Linux arm64 now that Chrome is supported.

rust/tests/config_tests.rs

exec_driver_tests.rsRefine exec-driver test skips to only exclude Edge on Linux arm64 +2/-2

Refine exec-driver test skips to only exclude Edge on Linux arm64

• Uses 'is_linux_arm64()' and updates skip logic so Linux arm64 continues testing Firefox/Chrome paths while skipping unsupported Edge.

rust/tests/exec_driver_tests.rs

offline_tests.rsSimplify offline test to always use Chrome +5/-14

Simplify offline test to always use Chrome

• Removes the Linux arm64 conditional browser selection and always runs the offline flow with Chrome.

rust/tests/offline_tests.rs

version_unit_tests.rsRemove unused SeleniumManager import +0/-1

Remove unused SeleniumManager import

• Drops an unused import to reduce warnings and keep the unit test focused on version parsing behavior.

rust/tests/version_unit_tests.rs

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. ARM misread as arm64 ✓ Resolved 🐞 Bug ≡ Correctness

Description

ChromeManager::get_platform_label() now maps any arch matching ARCH::ARM64 to "linux-arm64", but
ARCH::ARM64 also treats the alias "arm" as ARM64. This can cause 32-bit ARM requests (e.g., "--arch
arm") to select linux-arm64 Chrome/driver artifacts and fail or retrieve incompatible binaries.

Code

rust/src/chrome.rs[R517-518]

+        } else if ARM64.is(arch) {
+            "linux-arm64"

Evidence

The new linux-arm64 mapping is triggered by ARM64.is(arch) in get_platform_label(). The
architecture matcher for ARCH::ARM64 explicitly includes "arm" as an alias, so an arch value
of "arm" will now be treated as ARM64 and mapped to the linux-arm64 CfT platform label.

rust/src/chrome.rs[506-520]
rust/src/config.rs[189-205]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`get_platform_label()` uses `ARM64.is(arch)` to decide whether to return `"linux-arm64"`. However, `ARCH::ARM64` currently accepts the string alias `"arm"`, which can represent 32-bit ARM, not ARM64. This makes `--arch arm` route to the ARM64 download platform label.

### Issue Context
- `ARCH::ARM64` includes `"arm"` as an alias.
- The PR introduced an `ARM64` branch in `ChromeManager::get_platform_label()` that returns `"linux-arm64"`.

### Fix Focus Areas
- Prefer one of:
 - Remove `"arm"` from the ARM64 alias list (and/or move it to ARMV7), OR
 - Make the linux-arm64 branch stricter (match only `"arm64"`/`"aarch64"` explicitly) and let `"arm"` be handled as ARMV7/unsupported.
- Consider adding/adjusting a regression test for `--os linux --arch arm` to ensure it does not map to `linux-arm64`.

- rust/src/chrome.rs[506-520]
- rust/src/config.rs[189-205]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. arm now means ARMV7 ✗ Dismissed 📘 Rule violation ≡ Correctness ⭐ New

Description

The alias arm was moved from ARCH::ARM64 to ARCH::ARMV7, which changes the user-visible
behavior of --arch arm and can break existing scripts that previously relied on it selecting
arm64. Add explicit compatibility guidance (warning/error + docs/help text) so callers know to use
arm64/aarch64 for 64-bit.

Code

rust/src/config.rs[R195-197]

+            ARCH::ARM64 => vec![ARCH_ARM64, "aarch64"],
+            // "arm" is the conventional name for 32-bit ARM (e.g. std::env::consts::ARCH)
+            ARCH::ARMV7 => vec![ARCH_ARM7L, "armv7l", "arm"],

Evidence

PR Compliance ID 389266 requires maintaining backward-compatible public API/behavior. The changed
alias list removes arm from ARCH::ARM64 and adds it to ARCH::ARMV7, and the CLI passes
--arch directly into normalization logic, so --arch arm now resolves to 32-bit ARM instead of
arm64.

Rule 389266: Maintain backward-compatible public API and ABI
rust/src/config.rs[195-197]
rust/src/lib.rs[1388-1398]
rust/src/main.rs[94-97]
rust/tests/config_unit_tests.rs[82-99]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The meaning of `--arch arm` changed: it no longer matches `ARCH::ARM64` and instead matches `ARCH::ARMV7`. This is a user-visible behavior change that can break existing callers and should provide migration guidance.

## Issue Context
`ARCH::to_str_vector()` drives `ARCH::is()` matching, which is used by `get_normalized_arch()` to normalize the CLI-provided `--arch` value.

## Fix Focus Areas
- rust/src/config.rs[195-197]
- rust/src/lib.rs[1388-1402]
- rust/src/main.rs[94-97]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Extra URL allocations ✓ Resolved 🐞 Bug ➹ Performance

Description

ChromeManager::find_platform_url() always clones the URL String, but it is called inside per-version
filters (e.g., request_good_driver_version_from_online) where the result is only checked with
is_some(), causing unnecessary allocations while scanning many versions.

Code

rust/src/chrome.rs[R137-140]

+        downloads
+            .iter()
+            .find(|p| p.platform.eq_ignore_ascii_case(self.get_platform_label()))
+            .map(|p| p.url.to_string())

Evidence

The helper allocates a new String for the URL, and the driver-version scan calls it inside a filter
over all known-good versions while only using .is_some(), which implies repeated unnecessary
allocations during that scan.

rust/src/chrome.rs[136-141]
rust/src/chrome.rs[225-235]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ChromeManager::find_platform_url()` returns `Option<String>` and clones the URL via `to_string()`. In filtering code paths that iterate across many versions, the helper is used only to check availability (`.is_some()`), so the URL is repeatedly allocated and immediately dropped.

### Issue Context
This was introduced by adding the generic `find_platform_url()` helper and then reusing it both for (a) “does this version have a download for my platform?” checks and (b) “store the chosen URL for later download” assignments.

### Fix Focus Areas
- rust/src/chrome.rs[136-141]
- rust/src/chrome.rs[225-235]

### Suggested fix
- Split the helper into a non-allocating predicate / borrowed lookup, e.g.:
 - `fn has_platform_download(&self, downloads: &[PlatformUrl]) -> bool` (uses `.any(...)`)
 - and/or `fn find_platform_url_ref<'a>(&self, downloads: &'a [PlatformUrl]) -> Option<&'a str>`
- Use the boolean/borrowed helper in `filter(...)` paths.
- Only allocate (`to_string()`) at the point where you assign into `self.driver_url` / `self.browser_url`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: ⚖️ Balanced: This changes platform detection and download/version resolution across multiple Chrome paths and tests, with meaningful cross-platform behavioral risk, but is not sufficiently defect-dense to justify extended review.

Tip of the day

💡 Did you know, you can commit Qodo's fix in one click with committable suggestions (GitHub & GitLab)

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 08f24c4

Results up to commit 84cb7f5 ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Extra URL allocations ✓ Resolved 🐞 Bug ➹ Performance

Description

ChromeManager::find_platform_url() always clones the URL String, but it is called inside per-version
filters (e.g., request_good_driver_version_from_online) where the result is only checked with
is_some(), causing unnecessary allocations while scanning many versions.

Code

rust/src/chrome.rs[R137-140]

+        downloads
+            .iter()
+            .find(|p| p.platform.eq_ignore_ascii_case(self.get_platform_label()))
+            .map(|p| p.url.to_string())

Evidence

The helper allocates a new String for the URL, and the driver-version scan calls it inside a filter
over all known-good versions while only using .is_some(), which implies repeated unnecessary
allocations during that scan.

rust/src/chrome.rs[136-141]
rust/src/chrome.rs[225-235]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ChromeManager::find_platform_url()` returns `Option<String>` and clones the URL via `to_string()`. In filtering code paths that iterate across many versions, the helper is used only to check availability (`.is_some()`), so the URL is repeatedly allocated and immediately dropped.

### Issue Context
This was introduced by adding the generic `find_platform_url()` helper and then reusing it both for (a) “does this version have a download for my platform?” checks and (b) “store the chosen URL for later download” assignments.

### Fix Focus Areas
- rust/src/chrome.rs[136-141]
- rust/src/chrome.rs[225-235]

### Suggested fix
- Split the helper into a non-allocating predicate / borrowed lookup, e.g.:
 - `fn has_platform_download(&self, downloads: &[PlatformUrl]) -> bool` (uses `.any(...)`)
 - and/or `fn find_platform_url_ref<'a>(&self, downloads: &'a [PlatformUrl]) -> Option<&'a str>`
- Use the boolean/borrowed helper in `filter(...)` paths.
- Only allocate (`to_string()`) at the point where you assign into `self.driver_url` / `self.browser_url`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Results up to commit a3f2d83 ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ARM misread as arm64 ✓ Resolved 🐞 Bug ≡ Correctness

Description

ChromeManager::get_platform_label() now maps any arch matching ARCH::ARM64 to "linux-arm64", but
ARCH::ARM64 also treats the alias "arm" as ARM64. This can cause 32-bit ARM requests (e.g., "--arch
arm") to select linux-arm64 Chrome/driver artifacts and fail or retrieve incompatible binaries.

Code

rust/src/chrome.rs[R517-518]

+        } else if ARM64.is(arch) {
+            "linux-arm64"

Evidence

The new linux-arm64 mapping is triggered by ARM64.is(arch) in get_platform_label(). The
architecture matcher for ARCH::ARM64 explicitly includes "arm" as an alias, so an arch value
of "arm" will now be treated as ARM64 and mapped to the linux-arm64 CfT platform label.

rust/src/chrome.rs[506-520]
rust/src/config.rs[189-205]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`get_platform_label()` uses `ARM64.is(arch)` to decide whether to return `"linux-arm64"`. However, `ARCH::ARM64` currently accepts the string alias `"arm"`, which can represent 32-bit ARM, not ARM64. This makes `--arch arm` route to the ARM64 download platform label.

### Issue Context
- `ARCH::ARM64` includes `"arm"` as an alias.
- The PR introduced an `ARM64` branch in `ChromeManager::get_platform_label()` that returns `"linux-arm64"`.

### Fix Focus Areas
- Prefer one of:
 - Remove `"arm"` from the ARM64 alias list (and/or move it to ARMV7), OR
 - Make the linux-arm64 branch stricter (match only `"arm64"`/`"aarch64"` explicitly) and let `"arm"` be handled as ARMV7/unsupported.
- Consider adding/adjusting a regression test for `--os linux --arch arm` to ensure it does not map to `linux-arm64`.

- rust/src/chrome.rs[506-520]
- rust/src/config.rs[189-205]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit a3f2d83

[qodo-code-review]

Code review by qodo was updated up to the latest commit 680d018

[dennisameling]

Confirming that this is working as expected on a Linux arm64 machine:

Chrome 152:

$ cargo run -- --browser chrome --browser-version 152 --os linux --arch arm64 --force-browser-download --debug 
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/selenium-manager --browser chrome --browser-version 152 --os linux --arch arm64 --force-browser-download --debug`
[2026-08-13T08:12:32.762Z DEBUG] chromedriver not found in PATH
[2026-08-13T08:12:32.771Z WARN ] There was an error managing chrome; using browser found in the cache
[2026-08-13T08:12:32.771Z ERROR] chrome 152 not available for download on arm64 (minimum version: 153). Check available versions at https://googlechromelabs.github.io/chrome-for-testing/

Chrome 153:

$ cargo run -- --browser chrome --browser-version 153 --arch arm64 --force-browser-download --debug 
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s
     Running `target/debug/selenium-manager --browser chrome --browser-version 153 --arch arm64 --force-browser-download --debug`
[2026-08-13T08:12:53.057Z DEBUG] chromedriver not found in PATH
[2026-08-13T08:12:53.059Z DEBUG] Required browser: chrome 153.0.8005.0
[2026-08-13T08:12:53.059Z DEBUG] chrome 153.0.8005.0 already exists at /home/parallels/.cache/selenium/chrome/linux-arm64/153.0.8005.0/chrome
[2026-08-13T08:12:53.060Z DEBUG] chrome 153.0.8005.0 is available at /home/parallels/.cache/selenium/chrome/linux-arm64/153.0.8005.0/chrome
[2026-08-13T08:12:53.061Z DEBUG] Required driver: chromedriver 153.0.8005.0
[2026-08-13T08:12:53.061Z DEBUG] chromedriver 153.0.8005.0 already in the cache
[2026-08-13T08:12:53.062Z INFO ] Driver path: /home/parallels/.cache/selenium/chromedriver/linux-arm64/153.0.8005.0/chromedriver
[2026-08-13T08:12:53.062Z INFO ] Browser path: /home/parallels/.cache/selenium/chrome/linux-arm64/153.0.8005.0/chrome

[qodo-code-review]

No code changes since the last review — review skipped

[cgoldberg]

ignore my last comment.. I just saw "browser_latest_download_test will fail on Linux arm64 until version 153 of Chrome for Testing has been promoted to stable." :)

expected failure until version 153 of Chrome for Testing has been promoted to stable.

[dennisameling]

Just a few more days... The dev and beta channels have now reached v153, with stable scheduled for Wednesday the 26th: https://googlechromelabs.github.io/chrome-for-testing/ and https://chromestatus.com/roadmap.

That's an Early Stable Release, with the Stable Release following on Sep 8th. Let's just keep an eye at the Chrome for Testing page for the actual state of things.

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📜 Skill insights (0)

1. Chrome download regressions go unseen 📘 Rule violation ☼ Reliability

Description

find_platform_url and min_version_for_platform add platform-matching and minimum-version
decisions without focused unit coverage. The added tests launch Selenium Manager and download real
browsers, so missing-platform, case-insensitive-label, ordering, and minimum-boundary regressions
are not isolated and require slow external flows to surface.

Code

rust/src/chrome.rs[R136-139]

+    fn find_platform_url<'a>(&self, downloads: &'a [PlatformUrl]) -> Option<&'a str> {
+        downloads
+            .iter()
+            .find(|p| p.platform.eq_ignore_ascii_case(self.get_platform_label()))

Evidence

Compliance rule 4 requires focused unit tests where practical. The new helpers operate on ordinary
manager configuration and in-memory download metadata, but the changed tests exercise command-level
browser downloads and contain no direct coverage of either helper or the platform-availability
selection behavior.

AGENTS.md: Prefer Small Unit Tests and Avoid Contract-Distorting Mocks
rust/src/chrome.rs[136-150]
rust/src/chrome.rs[222-234]
rust/tests/browser_download_tests.rs[26-97]
rust/tests/browser_tests.rs[176-201]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new platform URL and minimum-version logic lacks small, deterministic unit tests.

## Issue Context
Current coverage invokes the Selenium Manager executable and real download flows. Add contract-faithful tests using in-memory platform and version metadata, covering case-insensitive matching, absent platforms, Linux arm64 minimums, other platforms, and selection of the newest usable version.

## Fix Focus Areas
- rust/src/chrome.rs[136-150]
- rust/src/chrome.rs[222-234]
- rust/src/chrome.rs[506-520]
- rust/tests/browser_download_tests.rs[26-97]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Arm Linux users cannot launch Chrome ✓ Resolved 📘 Rule violation ≡ Correctness

Description

get_platform_label adds linux-arm64 only to the Rust manager, while Python has no matching
binary selection and Java still rejects Linux Arm. When users invoke Selenium Manager through those
bindings, execution stops before this new Chrome path; Ruby, .NET, and JavaScript also package only
the generic Linux artifact.

Code

rust/src/chrome.rs[R517-518]

+        } else if ARM64.is(arch) {
+            "linux-arm64"

Evidence

Compliance rule 3 requires parity across applicable bindings for user-visible shared functionality.
The Rust manager recognizes linux-arm64, but Python's selector omits that platform, Java rejects
it explicitly, and the remaining bindings consume only the generic Linux artifact despite CI
producing a separate arm64 binary.

AGENTS.md: Maintain Cross-Binding Consistency for User-Visible Behavior
rust/src/chrome.rs[506-520]
py/selenium/webdriver/common/selenium_manager.py[90-102]
py/test/unit/selenium/webdriver/common/selenium_manager_tests.py[76-80]
java/src/org/openqa/selenium/manager/SeleniumManager.java[205-219]
common/selenium_manager.bzl[6-14]
.github/workflows/ci-rust.yml[311-317]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Rust manager supports Chrome on Linux arm64, but the language bindings do not consistently select or package the available arm64 manager artifact.

## Issue Context
Python and Java explicitly reject Linux arm64, while Ruby, .NET, and JavaScript package only the generic Linux binary. Update each applicable binding and its tests so users can reach the new Rust behavior.

## Fix Focus Areas
- rust/src/chrome.rs[517-518]
- py/selenium/webdriver/common/selenium_manager.py[90-102]
- py/test/unit/selenium/webdriver/common/selenium_manager_tests.py[76-80]
- java/src/org/openqa/selenium/manager/SeleniumManager.java[205-219]
- rb/BUILD.bazel[14-18]
- javascript/selenium-webdriver/BUILD.bazel[326-330]
- dotnet/src/webdriver/BUILD.bazel[152-156]
- common/selenium_manager.bzl[6-14]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: ⚖️ Balanced: This changes platform detection and download/version resolution across multiple Chrome paths and tests, with meaningful cross-platform behavioral risk, but is not sufficiently defect-dense to justify extended review.

Tip of the day

💡 Did you know, you can commit Qodo's fix in one click with committable suggestions (GitHub & GitLab)

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[dennisameling]

v153 has been released and the binaries are now available: https://googlechromelabs.github.io/chrome-for-testing/

I just rebased the PR and can confirm all tests are passing locally in my Linux arm64 VM. If a maintainer could approve the workflow run, I think CI should become green 😊

[mkurz]

AWESOME!

[cgoldberg]

If a maintainer could approve the workflow run

it's running now

[titusfortner]

Oh, for some reason I was thinking we needed to update our pinned browsers before running these tests, but that doesn't make sense. I'll start the release as soon as we merge this and one other thing.

[mkurz]

as soon as we merge this and one other thing.

what is the other thing?

will the chrome driver actually be downloaded automatically or does it need to be installed manually (sorry I did not look in the code ;)

[cgoldberg]

will the chrome driver actually be downloaded automatically

yup

[titusfortner]

@mkurz 4.49.0 is released if you want to try it out and let us know how it works.

[mkurz]

@mkurz 4.49.0 is released if you want to try it out and let us know how it works.

Great! Hopefully I find time tonight, if not tomorrow, thanks!