[build] ship prebuilt Selenium Manager Linux arm64 binary in all bindings

[titusfortner]

🔗 Related Issues

Ships the binary added in #16045

💥 What does this PR do?

• Ships the Linux arm64 Selenium Manager binary in each binding, so arm64 Linux users get a native binary instead of an x86_64 one.
• Linux ARM64 users will be able to get Firefox binaries immediately; Edge binaries are still not supported; Chrome needs [rust] Add support for Chrome arm64 on Linux #17915 to work.
• Python users can now use Selenium Manager on Windows ARM64 systems via emulation rather than raising, matching the other four bindings
• We've been going back and forth on naming; this consolidates on arm64 over aarch64 everywhere we choose a name.

🔧 Implementation Notes

• arm64 over aarch64: NuGet's runtimes/linux-arm64/ is a shipped path we cannot rename, so aarch64 would guarantee two spellings in published artifacts while arm64 allows one. This also matches our telemetry which consolidated on arm64. aarch64 remains only in values we read.
• Binaries move to linux-x86_64/ and linux-arm64/; macos/ and windows/ stay unqualified because each ships a single binary. .NET uses runtimes/linux-x64/ and runtimes/linux-arm64/ — NuGet Runtime Identifiers, and linux-musl-x64 resolves through them.
• Verified on an ubuntu-24.04-arm runner: the driver_finder specs resolve bin/linux-arm64/selenium-manager, execute it, and download working drivers for Firefox, and for Chrome with [rust] Add support for Chrome arm64 on Linux #17915 applied.
• CI display setup was gated on inputs.os == 'ubuntu', which skipped ubuntu-24.04-arm; it now uses contains.

🤖 AI assistance

• AI assisted (complete below)
  • Tool(s): Claude Code (Opus 5)
  • What was generated: the build wiring, binding changes, the arm64 CI verification, and this description
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

• common/selenium_manager.bzl still pins the old artifact names; I'll run ./go update_manager and commit the regenerated pins after ci-rust workflow runs from the trunk merge.
• Need to update our documentation after the next release: https://www.selenium.dev/documentation/selenium_manager/#alternative-architectures
• Windows ARM64 keeps using the x86_64 binary under emulation; no native binary is built.

🔄 Types of changes

• New feature (non-breaking change which adds functionality and tests!)

[qodo-code-review]

PR Summary by Qodo

Ship Linux arm64 Selenium Manager across all bindings

✨ Enhancement 🧪 Tests ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Bundles native Linux arm64 Selenium Manager binaries across all language bindings.
• Selects architecture-specific Linux binaries while retaining Windows arm64 emulation.
• Standardizes artifact naming and enables Ubuntu ARM CI setup and verification.

Diagram

graph TD
  CI["Rust CI"] --> ART["Release artifacts"] --> BZ["Bazel manager"] --> PKG["Binding packages"] --> SEL["Runtime selection"] --> BIN["Native manager"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Download binaries on demand

• ➕ Reduces binding package sizes
• ➕ Allows architecture support without republishing every binding
• ➖ Introduces a network dependency before Selenium Manager can run
• ➖ Weakens offline operation and packaged-version reproducibility
• ➖ Adds download, verification, caching, and failure-handling logic to every binding

2. Publish architecture-specific binding packages

• ➕ Each installation contains only its required native binary
• ➕ Avoids runtime architecture selection
• ➖ Fragments releases and package coordinates across ecosystems
• ➖ Complicates dependency resolution and migration for users
• ➖ Is not consistently supported by all five binding package managers

Recommendation: Bundling both Linux binaries in each existing binding package is the best approach. It preserves offline and deterministic behavior, keeps package identities stable, and follows existing Selenium Manager distribution patterns; the package-size increase is preferable to cross-ecosystem package fragmentation or bootstrap downloads.

Files changed (26) +236 / -133

Enhancement (15) +116 / -46

BUILD.bazelExpose separate Linux manager aliases +11/-3

Expose separate Linux manager aliases

• Splits the generic Linux alias into x86_64 and arm64 targets, each selecting its corresponding pinned download or Rust build.

common/manager/BUILD.bazel

BUILD.bazelPackage both Linux binaries for .NET +12/-4

Package both Linux binaries for .NET

• Creates separate Bazel copy targets for Linux x86_64 and arm64 binaries and includes both in the WebDriver NuGet package inputs.

dotnet/src/webdriver/BUILD.bazel

SeleniumManager.csProbe architecture-specific Linux NuGet assets +10/-3

Probe architecture-specific Linux NuGet assets

• Selects the 'linux-arm64' or 'linux-x64' NuGet runtime directory from the process architecture. Legacy .NET Framework builds continue to use x64.

dotnet/src/webdriver/Manager/SeleniumManager.cs

Selenium.WebDriver.csprojBuild and pack Linux RID assets +3/-2

Build and pack Linux RID assets

• Builds both Linux manager targets and packages them under the standard 'linux-x64' and 'linux-arm64' NuGet runtime identifiers.

dotnet/src/webdriver/Selenium.WebDriver.csproj

Selenium.WebDriver.nuspecAdd Linux arm64 NuGet runtime asset +2/-1

Add Linux arm64 NuGet runtime asset

• Moves the existing Linux binary to the x64 RID path and adds the arm64 binary under the corresponding NuGet runtime path.

dotnet/src/webdriver/Selenium.WebDriver.nuspec

Selenium.WebDriver.propsCopy both Linux RID binaries to outputs +9/-2

Copy both Linux RID binaries to outputs

• Replaces the generic Linux content entry with separate x64 and arm64 runtime assets for consuming projects.

dotnet/src/webdriver/assets/nuget/build/Selenium.WebDriver.props

BUILD.bazelEmbed both Linux binaries in Java artifacts +11/-4

Embed both Linux binaries in Java artifacts

• Replaces the generic Linux resource with architecture-qualified x86_64 and arm64 resources in the Java export.

java/src/org/openqa/selenium/manager/BUILD.bazel

SeleniumManager.javaEnable Selenium Manager on Linux arm64 +5/-7

Enable Selenium Manager on Linux arm64

• Removes the Linux ARM rejection and selects the arm64 resource for 'aarch64' JVMs. Other Linux and compatible Unix hosts use the x86_64 resource.

java/src/org/openqa/selenium/manager/SeleniumManager.java

BUILD.bazelShip both Linux binaries in the npm package +11/-4

Ship both Linux binaries in the npm package

• Adds architecture-specific copy targets and includes both Linux Selenium Manager binaries in the JavaScript package.

javascript/selenium-webdriver/BUILD.bazel

seleniumManager.jsSelect the Node.js Linux binary by architecture +2/-2

Select the Node.js Linux binary by architecture

• Reads the Node.js process architecture and chooses either the 'linux-arm64' or 'linux-x86_64' packaged directory.

javascript/selenium-webdriver/common/seleniumManager.js

BUILD.bazelPackage architecture-specific Python binaries +13/-5

Package architecture-specific Python binaries

• Creates arm64 and x86_64 Linux manager targets, includes both as Python library data, and updates packaging exclusions accordingly.

py/BUILD.bazel

selenium_manager.pyResolve arm64 Linux and Windows binaries +8/-3

Resolve arm64 Linux and Windows binaries

• Maps Linux and BSD aarch64 hosts to the arm64 binary and x86_64 hosts to the renamed x86_64 directory. Windows and Cygwin arm64 now use the x86_64 Windows binary through emulation.

py/selenium/webdriver/common/selenium_manager.py

BUILD.bazelShip both Linux binaries in the Ruby gem +11/-4

Ship both Linux binaries in the Ruby gem

• Creates architecture-specific copy targets and includes both Linux Selenium Manager executables in the Ruby package.

rb/BUILD.bazel

selenium_manager.rbSelect the Ruby Linux binary by host CPU +6/-2

Select the Ruby Linux binary by host CPU

• Introduces architecture-aware Linux directory selection, mapping an aarch64 host CPU to arm64 and defaulting other Linux and Unix systems to x86_64.

rb/lib/selenium/webdriver/common/selenium_manager.rb

selenium_manager.rbsDeclare the Linux directory selector +2/-0

Declare the Linux directory selector

• Adds the new 'linux_directory' helper to the Ruby type signature.

rb/sig/lib/selenium/webdriver/common/selenium_manager.rbs

Refactor (1) +26 / -46

BUILD.bazelGenerate platform-specific manager aliases +26/-46

Generate platform-specific manager aliases

• Refactors repeated platform aliases into a generated list and adds separate Linux arm64 and x86_64 targets. Matching hosts use local builds while other hosts use pinned artifacts.

rust/BUILD.bazel

Tests (4) +26 / -12

BUILD.bazelProvide both Linux binaries to .NET tests +2/-1

Provide both Linux binaries to .NET tests

• Adds the arm64 and x86_64 Selenium Manager targets to the WebDriver test filegroup.

dotnet/test/webdriver/BUILD.bazel

selenium_manager_tests.pyTest Python arm64 binary resolution +10/-8

Test Python arm64 binary resolution

• Updates expected x86_64 paths and verifies Linux aarch64 resolves the native arm64 binary. Changes Windows arm64 coverage from expecting an error to expecting the emulated Windows binary.

py/test/unit/selenium/webdriver/common/selenium_manager_tests.py

BUILD.bazelProvide both Linux binaries to Ruby integration tests +2/-1

Provide both Linux binaries to Ruby integration tests

• Replaces the generic Linux manager test dependency with arm64 and x86_64 targets.

rb/spec/integration/selenium/webdriver/BUILD.bazel

selenium_manager_spec.rbTest Ruby Linux architecture selection +12/-2

Test Ruby Linux architecture selection

• Updates x86_64 path expectations and adds coverage proving that an aarch64 host selects the Linux arm64 binary.

rb/spec/unit/selenium/webdriver/common/selenium_manager_spec.rb

Other (6) +68 / -29

bazel.ymlRun Ubuntu setup steps on ARM runners +2/-2

Run Ubuntu setup steps on ARM runners

• Broadens Ubuntu condition checks so disk cleanup, Fluxbox, and Xvfb setup also run for named ARM Ubuntu runners such as 'ubuntu-24.04-arm'.

.github/workflows/bazel.yml

ci-rust.ymlPublish architecture-qualified Linux artifacts +11/-11

Publish architecture-qualified Linux artifacts

• Renames Linux release and debug artifacts to explicit 'x86_64' and 'arm64' variants. Updates checksums, release metadata, and uploaded paths to use the standardized names.

.github/workflows/ci-rust.yml

MODULE.bazelRegister both Linux artifact repositories +2/-1

Register both Linux artifact repositories

• Replaces the generic Linux Selenium Manager repository with separate arm64 and x86_64 repositories.

MODULE.bazel

BUILD.bazelDefine host OS and architecture configurations +19/-0

Define host OS and architecture configurations

• Adds Bazel configuration settings for arm64 and x86_64 hosts on Linux, macOS, and Windows, enabling architecture-aware artifact selection.

common/BUILD.bazel

selenium_manager.bzlPin architecture-specific Selenium Manager artifacts +18/-11

Pin architecture-specific Selenium Manager artifacts

• Adds a dedicated Linux arm64 download repository and renames the x86_64 repository. Refreshes Selenium Manager binary, SBOM, and notice URLs and checksums to a newer artifact release.

common/selenium_manager.bzl

selenium_manager.pyGenerate pins for both Linux architectures +16/-4

Generate pins for both Linux architectures

• Splits Linux Bazel pin generation into x86_64 and arm64 entries and reads the corresponding checksum keys from release metadata.

scripts/selenium_manager.py

[qodo-code-review]

Code Review by Qodo

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

1. Linux ARM users remain unsupported ✗ Dismissed 🐞 Bug ≡ Correctness ⭐ New

Description

_get_binary() maps Linux ARM only when platform.machine().lower() is exactly aarch64, while
its exact lookup has no arm64 alias. A Linux ARM64 interpreter reporting arm64 therefore reaches
the unsupported platform/architecture exception instead of the packaged linux-arm64 manager,
despite that spelling already being accepted for Windows and Cygwin.

Code

py/selenium/webdriver/common/selenium_manager.py[97]

+                ("linux", "aarch64"): "linux-arm64/selenium-manager",

Evidence

The selection table provides Linux ARM64 only for aarch64, and the normalization step aliases only
amd64; consequently an arm64 value cannot match the Linux entry and the absent lookup raises.
The same changed table demonstrates that arm64 is a recognized architecture spelling for other
platforms.

py/selenium/webdriver/common/selenium_manager.py[90-107]
py/selenium/webdriver/common/selenium_manager.py[120-122]
py/test/unit/selenium/webdriver/common/selenium_manager_tests.py[61-82]

Agent prompt

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

## Issue description
Normalize `arm64` and `aarch64` to the same Python architecture before Selenium Manager binary lookup, so Linux ARM64 installations select the packaged ARM64 executable regardless of their reported spelling.

## Issue Context
The lookup is exact after lowercasing `platform.machine()`. The new Linux mapping contains only `aarch64`, while the same table explicitly accepts `arm64` for Windows and Cygwin.

## Fix Focus Areas
- py/selenium/webdriver/common/selenium_manager.py[93-101]
- py/test/unit/selenium/webdriver/common/selenium_manager_tests.py[77-82]

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

---

2. Maintainers miss binary routing bugs 📘 Rule violation ☼ Reliability

Description

The .NET linuxRid selector and JavaScript getBinary() add architecture-dependent Linux paths
without focused tests for either route. Because the ARM runner only builds or tests Rust,
regressions in these binding-specific decisions can merge without exercising their native
architecture mappings.

Code

javascript/selenium-webdriver/common/seleniumManager.js[42]

+    linux: arch === 'arm64' ? 'linux-arm64' : 'linux-x86_64',

Evidence

PR Compliance ID 5 requires focused coverage for changed behavior. The cited production regions
introduce architecture-dependent binary routing, while repository searches found no .NET or
JavaScript tests for those mappings, and the ARM CI job cited below runs only Rust tests.

AGENTS.md: Add Focused Tests and Prefer Real API Contracts Over Mocks
dotnet/src/webdriver/Manager/SeleniumManager.cs[135-143]
javascript/selenium-webdriver/common/seleniumManager.js[38-43]
.github/workflows/ci-rust.yml[40-43]

Agent prompt

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

## Issue description
Add focused tests for the new Linux architecture-to-directory selection in the .NET and JavaScript bindings.

## Issue Context
Python and Ruby have focused tests for both x86_64 and ARM64 routing, but repository searches found no equivalent coverage for these selectors. The ARM CI jobs only build or test Rust and therefore do not exercise these binding-specific decisions.

## Fix Focus Areas
- dotnet/src/webdriver/Manager/SeleniumManager.cs[135-143]
- javascript/selenium-webdriver/common/seleniumManager.js[38-43]

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

---

3. Linux .NET tests lose the manager ✓ Resolved 🐞 Bug ≡ Correctness

Description

EnvironmentManager still looks up the removed manager/linux/selenium-manager runfile even though
the Bazel test data now stages only manager/linux-arm64/selenium-manager and
manager/linux-x86_64/selenium-manager; the resulting missing-runfile exception is caught, leaving
SE_MANAGER_PATH unset rather than pointing to the supplied manager. Every Bazel-driven .NET
WebDriver test that creates a local driver on Linux reaches this path, after which SeleniumManager
probes only application and assembly locations and never inspects the architecture-specific Bazel
test data paths.

Code

dotnet/test/webdriver/BUILD.bazel[R11-12]

+        "//dotnet/src/webdriver:manager-linux-arm64",
+        "//dotnet/src/webdriver:manager-linux-x86_64",

Evidence

The changed Bazel outputs replace the generic Linux manager runfile with architecture-qualified
targets, while the shared test bootstrap continues requesting the deleted generic path. That lookup
raises a missing-runfile exception which is swallowed, so no explicit SE_MANAGER_PATH override is
established; the production resolver then falls back to application- and assembly-directory probing,
neither of which covers the architecture-specific manager files staged as Bazel test data.

dotnet/test/webdriver/BUILD.bazel[3-18]
dotnet/test/webdriver/Infrastructure/Environment/EnvironmentManager.cs[91-110]
dotnet/src/webdriver/Manager/SeleniumManager.cs[66-75]
dotnet/src/webdriver/BUILD.bazel[153-162]
dotnet/test/webdriver/Infrastructure/Environment/EnvironmentManager.cs[91-115]
dotnet/src/webdriver/Manager/SeleniumManager.cs[121-190]
dotnet/test/webdriver/BUILD.bazel[8-15]

Agent prompt

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

## Issue description
Update the .NET test environment’s Selenium Manager runfile lookup because the Bazel test data now stages architecture-qualified Linux manager paths while `EnvironmentManager` still requests the deleted `manager/linux/selenium-manager` path. The resulting `FileNotFoundException` is swallowed, leaving `SE_MANAGER_PATH` unset and forcing unrelated fallback probing.

## Issue Context
Select `manager/linux-arm64/selenium-manager` or `manager/linux-x86_64/selenium-manager` according to the process architecture, matching the newly staged Bazel targets. Ensure Linux Bazel tests set `SE_MANAGER_PATH` to the supplied architecture-specific runfile rather than relying on application- or assembly-directory fallback locations.

## Fix Focus Areas
- dotnet/test/webdriver/BUILD.bazel[11-12]
- dotnet/src/webdriver/BUILD.bazel[153-162]
- dotnet/test/webdriver/Infrastructure/Environment/EnvironmentManager.cs[91-110]
- dotnet/test/webdriver/Infrastructure/Environment/EnvironmentManager.cs[101-115]

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

---

View high (1)

4. A redundant comment adds no rationale ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

common/BUILD.bazel labels the generated settings with # Per-(OS, arch) host config_settings.,
which only paraphrases the comprehension immediately below it. Because the list and generated names
already expose both dimensions, later readers gain no rationale or constraint from the comment and
must maintain redundant prose.

Code

common/BUILD.bazel[44]

+# Per-(OS, arch) host config_settings.

Evidence

Compliance rule 6 requires comments to explain rationale or non-obvious constraints rather than
paraphrase implementation. The added comment at line 44 merely names the operating-system and
architecture settings visibly generated by lines 45 onward.

AGENTS.md: Comments Must Explain Why Rather Than Restate What Code Does
common/BUILD.bazel[44-44]

Agent prompt

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

## Issue description
Remove the comment that merely restates the generated host configuration settings.

## Issue Context
The comprehension and its platform list already communicate that the settings combine operating system and architecture, so the comment supplies no rationale or non-obvious constraint.

## Fix Focus Areas
- common/BUILD.bazel[44-44]

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

---

5. Some Java ARM users get x86 code ✓ Resolved 🐞 Bug ≡ Correctness

Description

getBinary() recognizes only an os.arch value containing aarch64 as ARM64 and sends every other
Linux architecture to linux-x86_64. Linux JVMs reporting an existing ARM identifier such as arm,
or the alternate arm64 spelling, therefore receive an incompatible executable instead of the ARM64
binary or the previous unsupported-platform error.

Code

java/src/org/openqa/selenium/manager/SeleniumManager.java[R214-217]

+          folder =
+              System.getProperty("os.arch", "").toLowerCase().contains("aarch64")
+                  ? "linux-arm64"
+                  : "linux-x86_64";

Evidence

The new binary-selection ternary defaults every value except aarch64 to x86_64, while the
repository's Java architecture model explicitly includes arm as an ARM identifier. The package
contains separate x86_64 and ARM64 executables, so selecting the default is operational rather than
merely a naming discrepancy.

java/src/org/openqa/selenium/manager/SeleniumManager.java[211-223]
java/src/org/openqa/selenium/Architecture.java[48-60]
java/src/org/openqa/selenium/manager/BUILD.bazel[35-45]

Agent prompt

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

## Issue description
Java's Linux manager selection treats only `aarch64` as ARM64 and defaults all other architecture strings to x86_64, including recognized or alternate ARM identifiers.

## Issue Context
Normalize supported 64-bit ARM spellings to `linux-arm64`, retain `linux-x86_64` for known x86_64 spellings, and reject unsupported architectures such as 32-bit ARM rather than executing an incompatible binary. Add tests for `aarch64`, `arm64`, x86_64, and 32-bit ARM values.

## Fix Focus Areas
- java/src/org/openqa/selenium/manager/SeleniumManager.java[211-226]
- java/src/org/openqa/selenium/Architecture.java[48-60]

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

---

Context sources

✅ Web pages:

  🌐 cpu/BUILD

  🌐 bazelbuild/platforms

  🌐 Platforms

  +15 more

Review mode: 🧠 Deep: This push changes platform selection and packaged binaries across multiple bindings, build systems, CI workflows, and tests, creating many independent cross-platform paths where redundant review could catch subtle omissions.

Tip of the day

💡 Did you know, you can tweak Display preferences with a live preview to see your comment before it ships

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 615e50f

Results up to commit 4f7b348 🧠 Deep

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

1. Linux .NET tests lose the manager ✓ Resolved 🐞 Bug ≡ Correctness

Description

EnvironmentManager still looks up the removed manager/linux/selenium-manager runfile even though
the Bazel test data now stages only manager/linux-arm64/selenium-manager and
manager/linux-x86_64/selenium-manager; the resulting missing-runfile exception is caught, leaving
SE_MANAGER_PATH unset rather than pointing to the supplied manager. Every Bazel-driven .NET
WebDriver test that creates a local driver on Linux reaches this path, after which SeleniumManager
probes only application and assembly locations and never inspects the architecture-specific Bazel
test data paths.

Code

dotnet/test/webdriver/BUILD.bazel[R11-12]

+        "//dotnet/src/webdriver:manager-linux-arm64",
+        "//dotnet/src/webdriver:manager-linux-x86_64",

Evidence

The changed Bazel outputs replace the generic Linux manager runfile with architecture-qualified
targets, while the shared test bootstrap continues requesting the deleted generic path. That lookup
raises a missing-runfile exception which is swallowed, so no explicit SE_MANAGER_PATH override is
established; the production resolver then falls back to application- and assembly-directory probing,
neither of which covers the architecture-specific manager files staged as Bazel test data.

dotnet/test/webdriver/BUILD.bazel[3-18]
dotnet/test/webdriver/Infrastructure/Environment/EnvironmentManager.cs[91-110]
dotnet/src/webdriver/Manager/SeleniumManager.cs[66-75]
dotnet/src/webdriver/BUILD.bazel[153-162]
dotnet/test/webdriver/Infrastructure/Environment/EnvironmentManager.cs[91-115]
dotnet/src/webdriver/Manager/SeleniumManager.cs[121-190]
dotnet/test/webdriver/BUILD.bazel[8-15]

Agent prompt

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

## Issue description
Update the .NET test environment’s Selenium Manager runfile lookup because the Bazel test data now stages architecture-qualified Linux manager paths while `EnvironmentManager` still requests the deleted `manager/linux/selenium-manager` path. The resulting `FileNotFoundException` is swallowed, leaving `SE_MANAGER_PATH` unset and forcing unrelated fallback probing.

## Issue Context
Select `manager/linux-arm64/selenium-manager` or `manager/linux-x86_64/selenium-manager` according to the process architecture, matching the newly staged Bazel targets. Ensure Linux Bazel tests set `SE_MANAGER_PATH` to the supplied architecture-specific runfile rather than relying on application- or assembly-directory fallback locations.

## Fix Focus Areas
- dotnet/test/webdriver/BUILD.bazel[11-12]
- dotnet/src/webdriver/BUILD.bazel[153-162]
- dotnet/test/webdriver/Infrastructure/Environment/EnvironmentManager.cs[91-110]
- dotnet/test/webdriver/Infrastructure/Environment/EnvironmentManager.cs[101-115]

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

---

2. A redundant comment adds no rationale ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

common/BUILD.bazel labels the generated settings with # Per-(OS, arch) host config_settings.,
which only paraphrases the comprehension immediately below it. Because the list and generated names
already expose both dimensions, later readers gain no rationale or constraint from the comment and
must maintain redundant prose.

Code

common/BUILD.bazel[44]

+# Per-(OS, arch) host config_settings.

Evidence

Compliance rule 6 requires comments to explain rationale or non-obvious constraints rather than
paraphrase implementation. The added comment at line 44 merely names the operating-system and
architecture settings visibly generated by lines 45 onward.

AGENTS.md: Comments Must Explain Why Rather Than Restate What Code Does
common/BUILD.bazel[44-44]

Agent prompt

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

## Issue description
Remove the comment that merely restates the generated host configuration settings.

## Issue Context
The comprehension and its platform list already communicate that the settings combine operating system and architecture, so the comment supplies no rationale or non-obvious constraint.

## Fix Focus Areas
- common/BUILD.bazel[44-44]

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

---

3. Some Java ARM users get x86 code ✓ Resolved 🐞 Bug ≡ Correctness

Description

getBinary() recognizes only an os.arch value containing aarch64 as ARM64 and sends every other
Linux architecture to linux-x86_64. Linux JVMs reporting an existing ARM identifier such as arm,
or the alternate arm64 spelling, therefore receive an incompatible executable instead of the ARM64
binary or the previous unsupported-platform error.

Code

java/src/org/openqa/selenium/manager/SeleniumManager.java[R214-217]

+          folder =
+              System.getProperty("os.arch", "").toLowerCase().contains("aarch64")
+                  ? "linux-arm64"
+                  : "linux-x86_64";

Evidence

The new binary-selection ternary defaults every value except aarch64 to x86_64, while the
repository's Java architecture model explicitly includes arm as an ARM identifier. The package
contains separate x86_64 and ARM64 executables, so selecting the default is operational rather than
merely a naming discrepancy.

java/src/org/openqa/selenium/manager/SeleniumManager.java[211-223]
java/src/org/openqa/selenium/Architecture.java[48-60]
java/src/org/openqa/selenium/manager/BUILD.bazel[35-45]

Agent prompt

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

## Issue description
Java's Linux manager selection treats only `aarch64` as ARM64 and defaults all other architecture strings to x86_64, including recognized or alternate ARM identifiers.

## Issue Context
Normalize supported 64-bit ARM spellings to `linux-arm64`, retain `linux-x86_64` for known x86_64 spellings, and reject unsupported architectures such as 32-bit ARM rather than executing an incompatible binary. Add tests for `aarch64`, `arm64`, x86_64, and 32-bit ARM values.

## Fix Focus Areas
- java/src/org/openqa/selenium/manager/SeleniumManager.java[211-226]
- java/src/org/openqa/selenium/Architecture.java[48-60]

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

---

Results up to commit dd447b8 🧠 Deep

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

1. Maintainers miss binary routing bugs 📘 Rule violation ☼ Reliability

Description

The .NET linuxRid selector and JavaScript getBinary() add architecture-dependent Linux paths
without focused tests for either route. Because the ARM runner only builds or tests Rust,
regressions in these binding-specific decisions can merge without exercising their native
architecture mappings.

Code

javascript/selenium-webdriver/common/seleniumManager.js[42]

+    linux: arch === 'arm64' ? 'linux-arm64' : 'linux-x86_64',

Evidence

PR Compliance ID 5 requires focused coverage for changed behavior. The cited production regions
introduce architecture-dependent binary routing, while repository searches found no .NET or
JavaScript tests for those mappings, and the ARM CI job cited below runs only Rust tests.

AGENTS.md: Add Focused Tests and Prefer Real API Contracts Over Mocks
dotnet/src/webdriver/Manager/SeleniumManager.cs[135-143]
javascript/selenium-webdriver/common/seleniumManager.js[38-43]
.github/workflows/ci-rust.yml[40-43]

Agent prompt

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

## Issue description
Add focused tests for the new Linux architecture-to-directory selection in the .NET and JavaScript bindings.

## Issue Context
Python and Ruby have focused tests for both x86_64 and ARM64 routing, but repository searches found no equivalent coverage for these selectors. The ARM CI jobs only build or test Rust and therefore do not exercise these binding-specific decisions.

## Fix Focus Areas
- dotnet/src/webdriver/Manager/SeleniumManager.cs[135-143]
- javascript/selenium-webdriver/common/seleniumManager.js[38-43]

ⓘ 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 dd447b8

[qodo-code-review]

Code review by qodo was updated up to the latest commit 615e50f