[build] add stub mode option for using selenium manager with bazel - #18135

• Add a stub manager mode so pinned binary changes do not invalidate RBE CI tests.
• Keep host builds independent of non-host downloads and fail clearly if a stub runs.
• Preserve pinned manager assets when warming the release publishing cache.

graph TD
  CI["RBE CI"] -->|"stub"| Mode{"Manager mode"} --> Aliases["Manager aliases"] -->|"stub"| Stubs["Checked-in stubs"] --> Bindings["Binding packages"]
  Release["Release prep"] -->|"download"| Mode
  Aliases -->|"download"| Pinned["Pinned assets"] --> Bindings
  Aliases -->|"host"| Host["Host build"] --> Bindings
  Aliases -->|"host non-host"| Stubs

Loading

Selecting assets at the existing shared aliases is the appropriate approach: every binding already consumes them, so the change avoids divergent per-binding configuration. Removing manager assets from individual test inputs would require broader changes to packaging behavior; the explicit release override preserves the current publishing path.

Enhancement (4) +42 / -2

BUILD.bazelRoute manager binaries and metadata through stub selections +23/-2

Route manager binaries and metadata through stub selections

• Selects checked-in stubs for all platform binaries in stub mode and for the SBOM and notices in both stub and host modes. Existing aliases continue to supply downloaded assets for download mode.

common/manager/BUILD.bazel

stub-selenium-managerAdd a fail-fast Selenium Manager placeholder +5/-0

Add a fail-fast Selenium Manager placeholder

• Adds a shell-script stand-in that reports the selected stub or host mode and exits non-zero if executed.

common/manager/stub-selenium-manager

stub-selenium-manager-THIRD-PARTY-NOTICES.txtAdd placeholder manager notices +2/-0

Add placeholder manager notices

• Provides a checked-in notices file so stub and host bundles do not depend on the pinned notices download.

common/manager/stub-selenium-manager-THIRD-PARTY-NOTICES.txt

stub-selenium-manager.cdx.jsonAdd placeholder manager SBOM +12/-0

Add placeholder manager SBOM

• Provides a checked-in CycloneDX placeholder so stub and host bundles do not depend on the changing pinned SBOM.

common/manager/stub-selenium-manager.cdx.json

Documentation (1) +2 / -1

README.mdDocument stub and host manager modes +2/-1

Document stub and host manager modes

• Explains when to use stub mode and clarifies that host mode stubs other platforms.

README.md

Other (4) +15 / -3

.bazelrc.remoteSelect stub manager assets for RBE CI +1/-0

Select stub manager assets for RBE CI

• Sets '--manager=stub' in 'rbe-ci' so tests that bundle, but do not execute, Selenium Manager no longer depend on its pinned assets.

.bazelrc.remote

BUILD.bazelRegister the stub manager build setting +8/-0

Register the stub manager build setting

• Adds 'stub' as a valid manager value and exposes a matching Bazel configuration condition.

common/BUILD.bazel

BUILD.bazelStub non-host platforms in host mode +4/-2

Stub non-host platforms in host mode

• Changes host-mode platform aliases to use the checked-in stub instead of downloaded binaries when the platform does not match the host.

rust/BUILD.bazel

prepare-release.shOverride stub mode when warming release caches +2/-1

Override stub mode when warming release caches

• Passes '--manager=download' to the release-preparation build so its artifacts match publishing jobs that bundle the pinned manager.

scripts/github-actions/prepare-release.sh

Description

nuget_pack_impl now keys its layout by package path, but no focused test verifies that two labels
resolving to the same file retain both package entries. In stub mode, the .NET package maps multiple
manager aliases to distinct paths backed by the same script, while the existing release build
creates the package without checking those entries.

Code

dotnet/private/nuget_pack.bzl[50]

+        layout[name] = file.files.to_list()[0]

Evidence

Rule 4 calls for focused coverage of changed behavior. The layout now retains entries by destination
path, and the WebDriver package declares separate platform paths that resolve to the shared stub in
stub mode; the release target builds packages but does not assert their contents.

AGENTS.md: Cover Changes with Focused Tests That Exercise Real API Contracts
dotnet/private/nuget_pack.bzl[43-50]
dotnet/src/webdriver/BUILD.bazel[194-208]
dotnet/BUILD.bazel[9-19]

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 package-layout change is intended to retain distinct package paths when labels resolve to one file, but that behavior has no focused regression test.

## Fix Focus Areas
- dotnet/private/nuget_pack.bzl[43-50]
- dotnet/src/webdriver/BUILD.bazel[194-208]

## Recommended Fix
Add a focused package test that builds with shared manager stubs, opens the resulting package, and asserts that every expected manager path is present.

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

Dismiss ↗ | View ↗

Description

The new manager_stub selection in common/manager/BUILD.bazel has no test that builds the
platform aliases or checks their selected artifacts. Existing Python manager tests mock or inspect
platform paths rather than exercising the Bazel configurations, leaving both all-stub bundles and
the non-host artifacts in --manager=host unverified.

Code

common/manager/BUILD.bazel[47]

+        "//common:manager_stub": ":stub-selenium-manager",

Evidence

The changed aliases introduce artifact-selection behavior for the new mode, while the existing cited
tests only exercise Python path selection and do not build those aliases. No focused test was added
for the configured bundle outputs.

AGENTS.md: Add Focused Tests Without Misrepresentative Mocks
common/BUILD.bazel[16-40]
common/manager/BUILD.bazel[14-48]
py/test/unit/selenium/webdriver/common/selenium_manager_tests.py[43-103]

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 manager modes change bundled artifacts without a focused test of the Bazel selections.

## Fix Focus Areas
- common/manager/BUILD.bazel[14-48]
- common/BUILD.bazel[16-40]

## Recommended Fix
Add a small build-level test that verifies all platform aliases select stubs under `--manager=stub`, while `--manager=host` selects the host binary and stubs for other platforms. Check the stub's failure message where it can be executed.

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

Dismiss ↗ | View ↗

Description

The manager_host branch of selenium-manager-notice substitutes a placeholder for the third-party
notices even though that mode bundles a locally compiled Selenium Manager. Building a Java manager
artifact or .NET WebDriver package with --manager=host therefore pairs a real binary with a notice
file that contains none of its dependency notices; the corresponding SBOM is empty as well.

Code

common/manager/BUILD.bazel[64]

+        "//common:manager_host": ":stub-selenium-manager-THIRD-PARTY-NOTICES.txt",

Evidence

Host mode selects Rust manager aliases, which resolve to the locally compiled binary on the matching
platform. The snapshot workflow generates notices from its Rust dependencies, but the new host-mode
alias instead selects a two-line placeholder; both Java and .NET package that alias alongside the
manager binary.

common/manager/BUILD.bazel[13-18]
rust/BUILD.bazel[80-93]
rust/about.toml[1-28]
.github/workflows/sm-snapshot.yml[297-303]
common/manager/BUILD.bazel[53-67]
common/manager/stub-selenium-manager-THIRD-PARTY-NOTICES.txt[1-2]
common/manager/stub-selenium-manager.cdx.json[5-10]
java/src/org/openqa/selenium/manager/BUILD.bazel[8-22]
dotnet/src/webdriver/BUILD.bazel[194-208]

Agent prompt

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

## Issue description
Host-mode packages bundle a compiled Selenium Manager but substitute empty SBOM and third-party notices files.
## Fix Focus Areas
- common/manager/BUILD.bazel[53-67]
- rust/BUILD.bazel[113-146]
## Recommended Fix
Select metadata generated from the Rust dependency tree for `--manager=host`, or otherwise provide accurate third-party notices and an SBOM for the compiled binary. Keep placeholder metadata exclusive to configurations that bundle only stubs.

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

Description

The new --manager=stub setting also applies to ci-build.sh’s release-artifact build, replacing
the manager binaries and metadata in its packages with placeholders. On ordinary pull requests, that
build no longer checks the downloaded-manager package configuration used by the separate
release-preparation and publish builds.

Code

.bazelrc.remote[67]

+build:rbe-ci --manager=stub

Evidence

The ordinary CI workflow runs ci-build.sh, whose release-artifact build uses --config=rbe-ci
without an override. That configuration now selects the stub manager aliases; the Java manager
artifact is among the tagged release artifacts. Only the separate release-preparation script
restores --manager=download.

.github/workflows/ci-rbe.yml[43-60]
scripts/github-actions/ci-build.sh[27-31]
common/manager/BUILD.bazel[13-19]
java/src/org/openqa/selenium/manager/BUILD.bazel[12-23]
scripts/github-actions/prepare-release.sh[30-31]

Agent prompt

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

## Issue description
Ordinary RBE CI builds release artifacts with stubbed managers, so it does not validate the package configuration used for publishing.
## Fix Focus Areas
- scripts/github-actions/ci-build.sh[27-31]
- .bazelrc.remote[64-67]
## Recommended Fix
Keep stub mode for the RBE test command, but pass `--manager=download` to the release-artifact build, or otherwise add a CI build of those artifacts with downloaded managers.

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

Description

The selenium-manager-windows alias selects the POSIX shell script stub-selenium-manager, even
though the bindings package it as selenium-manager.exe. When a Windows stub-mode build invokes
that path, process creation fails before the script can print its guidance to use
--manager=download or --manager=all, leaving the Python binding with only an unsuccessful
command and preventing the .NET binding from receiving the diagnostic.

Code

common/manager/BUILD.bazel[47]

+        "//common:manager_stub": ":stub-selenium-manager",

Evidence

The Windows alias selects a file beginning #!/bin/sh, while the packaging rules place it at an
.exe path. The .NET binding starts that path directly as a process, and the Python binding catches
launch failures without the script's diagnostic; neither can obtain the guidance from a shell-script
body that never runs.

AGENTS.md: Provide Logging for User-Relevant Operations
common/manager/BUILD.bazel[44-50]
common/manager/stub-selenium-manager[1-5]
py/BUILD.bazel[124-128]
py/selenium/webdriver/common/selenium_manager.py[137-149]
common/manager/BUILD.bazel[43-49]
dotnet/src/webdriver/BUILD.bazel[185-203]
dotnet/src/webdriver/Manager/SeleniumManager.cs[263-284]

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 Windows manager alias packages a POSIX shell script as an `.exe`, so invoking the stub on Windows fails before it can print its configuration guidance.

## Fix Focus Areas
- common/manager/BUILD.bazel[43-50]
- common/manager/stub-selenium-manager[1-5]

## Recommended Fix
Select a Windows-native executable stub for the Windows alias that exits nonzero and prints the same guidance identifying the stub or host build mode and the `--manager=download` or `--manager=all` options. Keep the shell-script stub for platforms that can execute it, and verify that the packaged Windows artifact can be launched.

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

Description

test:rbe-ci --manager=stub applies the flag only to bazel test, so the `bazel build
--config=rbe-ci --build_tag_filters=release-artifact //... step that ci-build.sh` runs next uses a
different //common:manager value. Bazel throws away the analysis cache whenever a build option
changes between commands on the same server. That means every non-release-preparation CI run
analyses //... a second time, and the package build gets no reuse from the analysis the test step
just did.

Code

.bazelrc.remote[67]

+test:rbe-ci --manager=stub

Evidence

ci-build.sh runs bazel test --config=rbe-ci ... //... and then, in the same Bazel server, `bazel
build --config=rbe-ci --build_tag_filters=release-artifact //...`. Because the flag sits under
test:, the first command uses --manager=stub and the second uses the default download.
Changing a build option, Starlark flags included, makes Bazel discard its analysis cache.

scripts/github-actions/ci-build.sh[22-31]
.bazelrc.remote[64-67]

Agent prompt

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

## Issue description
`test:rbe-ci --manager=stub` makes the test step and the next `bazel build --config=rbe-ci` release-artifact step use different `//common:manager` values. Bazel then discards the analysis cache and analyses `//...` again.

## Fix Focus Areas
- .bazelrc.remote[67-67]
- scripts/github-actions/ci-build.sh[22-31]

## Recommended Fix
If the extra analysis time is acceptable, keep the split and add a comment saying it is intentional. If not, move the release-artifact build into its own Bazel output base or server (for example with a separate `--output_base`), or run it with an explicit flag ordering that keeps the analysis cache. The package build must keep using the downloaded manager.

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

Description

On Windows, the stub-selenium-manager-windows filegroup is marked @platforms//:incompatible, so
every binding library, package and browser test that depends on
//common/manager:selenium-manager-windows becomes incompatible too. Bazel reports an error only
for targets named explicitly; with a wildcard such as bazel test --manager=stub //... it skips
incompatible targets without reporting them, so a Windows run can end green with none of the browser
tests executed. That contradicts the commit's stated aim of failing at build time.

Code

common/manager/BUILD.bazel[R80-86]

+filegroup(
+    name = "stub-selenium-manager-windows",
+    srcs = ["stub-selenium-manager"],
+    target_compatible_with = select({
+        "//common:windows": ["@platforms//:incompatible"],
+        "//conditions:default": [],
+    }),

Evidence

The filegroup's target_compatible_with returns @platforms//:incompatible under
//common:windows, and incompatibility spreads to every target that depends on it. All bindings
consume the windows alias; .NET's webdriver-pack and manager-windows are examples. Bazel's
documented behaviour is to skip incompatible targets that a wildcard pattern matches and to error
only on targets requested explicitly. As a result, //... runs on Windows silently skip the tests
instead of failing.

common/manager/BUILD.bazel[44-50]
common/manager/BUILD.bazel[79-87]
dotnet/src/webdriver/BUILD.bazel[187-207]
common/BUILD.bazel[71-76]

Agent prompt

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

## Issue description
With `--manager=stub` on a Windows host, `stub-selenium-manager-windows` is marked incompatible. Every dependent target is then skipped silently when tests are selected with a wildcard such as `//...`, so the run passes without executing any tests.

## Fix Focus Areas
- common/manager/BUILD.bazel[79-87]

## Recommended Fix
Make the misconfiguration a hard error instead of an incompatibility. One option: in the `selenium-manager-windows` alias, select on a combined config (`selects.config_setting_group` from bazel_skylib, matching `//common:manager_stub` AND `//common:windows`) and add `no_match_error` so analysis fails. Another option: use a small rule that calls `fail("--manager=stub is not supported on Windows hosts; use --manager=download")` when built on Windows. Either way, a wildcard build should fail instead of skipping the targets.

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

Description

The stub notices file and stub SBOM property both say they are placeholders for a "--manager=host
build", but common/manager/BUILD.bazel also selects them under //common:manager_stub, which
rbe-ci now uses. Anyone who opens the SBOM or notices bundled into a Java jar, Python wheel, npm
or gem package from an rbe-ci build is told it came from a host build, which sends them looking in
the wrong place. The binary stub's message was updated to name both modes, so the three stubs now
disagree.

Code

common/manager/stub-selenium-manager-THIRD-PARTY-NOTICES.txt[R1-2]

+Placeholder notices file for a --manager=host build.
+The pinned or --manager=all build carries the real third-party notices for Selenium Manager.

Evidence

The SBOM and notice aliases send both manager_host and manager_stub to these files, and
.bazelrc.remote sets --manager=stub for rbe-ci. The text in these files still mentions only the
host build, while the binary stub names both --manager=stub and --manager=host.

common/manager/BUILD.bazel[53-68]
common/manager/stub-selenium-manager.cdx.json[6-11]
common/manager/stub-selenium-manager[4]
.bazelrc.remote[67]

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 stub notices file and stub SBOM say they are placeholders for a `--manager=host` build only, but `--manager=stub` (used by rbe-ci) also bundles them.

## Fix Focus Areas
- common/manager/stub-selenium-manager-THIRD-PARTY-NOTICES.txt[1-2]
- common/manager/stub-selenium-manager.cdx.json[9-9]

## Recommended Fix
Change the wording to "Placeholder ... for a --manager=stub or --manager=host build; a --manager=download or --manager=all build carries the real ...", matching the binary stub's message.

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

💡 Did you know, you can show, collapse, or hide each part of a finding: code, evidence, and all

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Review updated until commit a3fc80b

Results up to commit 4c36298 🧠 Deep

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

1. Placeholder licence files name the wrong build mode ✓ Resolved

Description

The stub notices file and stub SBOM property both say they are placeholders for a "--manager=host
build", but common/manager/BUILD.bazel also selects them under //common:manager_stub, which
rbe-ci now uses. Anyone who opens the SBOM or notices bundled into a Java jar, Python wheel, npm
or gem package from an rbe-ci build is told it came from a host build, which sends them looking in
the wrong place. The binary stub's message was updated to name both modes, so the three stubs now
disagree.

Code

common/manager/stub-selenium-manager-THIRD-PARTY-NOTICES.txt[R1-2]

+Placeholder notices file for a --manager=host build.
+The pinned or --manager=all build carries the real third-party notices for Selenium Manager.

Evidence

The SBOM and notice aliases send both manager_host and manager_stub to these files, and
.bazelrc.remote sets --manager=stub for rbe-ci. The text in these files still mentions only the
host build, while the binary stub names both --manager=stub and --manager=host.

common/manager/BUILD.bazel[53-68]
common/manager/stub-selenium-manager.cdx.json[6-11]
common/manager/stub-selenium-manager[4]
.bazelrc.remote[67]

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 stub notices file and stub SBOM say they are placeholders for a `--manager=host` build only, but `--manager=stub` (used by rbe-ci) also bundles them.

## Fix Focus Areas
- common/manager/stub-selenium-manager-THIRD-PARTY-NOTICES.txt[1-2]
- common/manager/stub-selenium-manager.cdx.json[9-9]

## Recommended Fix
Change the wording to "Placeholder ... for a --manager=stub or --manager=host build; a --manager=download or --manager=all build carries the real ...", matching the binary stub's message.

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

---

Results up to commit dab7e80 ⚖️ Balanced

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

1. Stub bundles have no focused build tests 📘 Rule violation ☼ Reliability

Description

The new manager_stub selection in common/manager/BUILD.bazel has no test that builds the
platform aliases or checks their selected artifacts. Existing Python manager tests mock or inspect
platform paths rather than exercising the Bazel configurations, leaving both all-stub bundles and
the non-host artifacts in --manager=host unverified.

Code

common/manager/BUILD.bazel[47]

+        "//common:manager_stub": ":stub-selenium-manager",

Evidence

The changed aliases introduce artifact-selection behavior for the new mode, while the existing cited
tests only exercise Python path selection and do not build those aliases. No focused test was added
for the configured bundle outputs.

AGENTS.md: Add Focused Tests Without Misrepresentative Mocks
common/BUILD.bazel[16-40]
common/manager/BUILD.bazel[14-48]
py/test/unit/selenium/webdriver/common/selenium_manager_tests.py[43-103]

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 manager modes change bundled artifacts without a focused test of the Bazel selections.

## Fix Focus Areas
- common/manager/BUILD.bazel[14-48]
- common/BUILD.bazel[16-40]

## Recommended Fix
Add a small build-level test that verifies all platform aliases select stubs under `--manager=stub`, while `--manager=host` selects the host binary and stubs for other platforms. Check the stub's failure message where it can be executed.

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

Dismiss ↗ | View ↗

---

2. Windows stub failures hide the remedy ✓ Resolved

Description

The selenium-manager-windows alias selects the POSIX shell script stub-selenium-manager, even
though the bindings package it as selenium-manager.exe. When a Windows stub-mode build invokes
that path, process creation fails before the script can print its guidance to use
--manager=download or --manager=all, leaving the Python binding with only an unsuccessful
command and preventing the .NET binding from receiving the diagnostic.

Code

common/manager/BUILD.bazel[47]

+        "//common:manager_stub": ":stub-selenium-manager",

Evidence

The Windows alias selects a file beginning #!/bin/sh, while the packaging rules place it at an
.exe path. The .NET binding starts that path directly as a process, and the Python binding catches
launch failures without the script's diagnostic; neither can obtain the guidance from a shell-script
body that never runs.

AGENTS.md: Provide Logging for User-Relevant Operations
common/manager/BUILD.bazel[44-50]
common/manager/stub-selenium-manager[1-5]
py/BUILD.bazel[124-128]
py/selenium/webdriver/common/selenium_manager.py[137-149]
common/manager/BUILD.bazel[43-49]
dotnet/src/webdriver/BUILD.bazel[185-203]
dotnet/src/webdriver/Manager/SeleniumManager.cs[263-284]

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 Windows manager alias packages a POSIX shell script as an `.exe`, so invoking the stub on Windows fails before it can print its configuration guidance.

## Fix Focus Areas
- common/manager/BUILD.bazel[43-50]
- common/manager/stub-selenium-manager[1-5]

## Recommended Fix
Select a Windows-native executable stub for the Windows alias that exits nonzero and prints the same guidance identifying the stub or host build mode and the `--manager=download` or `--manager=all` options. Keep the shell-script stub for platforms that can execute it, and verify that the packaged Windows artifact can be launched.

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

---

Results up to commit d3f1d75 ⚖️ Balanced

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

1. Shared package files lack a focused test 📘 Rule violation ☼ Reliability

Description

nuget_pack_impl now keys its layout by package path, but no focused test verifies that two labels
resolving to the same file retain both package entries. In stub mode, the .NET package maps multiple
manager aliases to distinct paths backed by the same script, while the existing release build
creates the package without checking those entries.

Code

dotnet/private/nuget_pack.bzl[50]

+        layout[name] = file.files.to_list()[0]

Evidence

Rule 4 calls for focused coverage of changed behavior. The layout now retains entries by destination
path, and the WebDriver package declares separate platform paths that resolve to the shared stub in
stub mode; the release target builds packages but does not assert their contents.

AGENTS.md: Cover Changes with Focused Tests That Exercise Real API Contracts
dotnet/private/nuget_pack.bzl[43-50]
dotnet/src/webdriver/BUILD.bazel[194-208]
dotnet/BUILD.bazel[9-19]

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 package-layout change is intended to retain distinct package paths when labels resolve to one file, but that behavior has no focused regression test.

## Fix Focus Areas
- dotnet/private/nuget_pack.bzl[43-50]
- dotnet/src/webdriver/BUILD.bazel[194-208]

## Recommended Fix
Add a focused package test that builds with shared manager stubs, opens the resulting package, and asserts that every expected manager path is present.

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

Dismiss ↗ | View ↗

---

2. CI no longer checks shippable packages ✓ Resolved

Description

The new --manager=stub setting also applies to ci-build.sh’s release-artifact build, replacing
the manager binaries and metadata in its packages with placeholders. On ordinary pull requests, that
build no longer checks the downloaded-manager package configuration used by the separate
release-preparation and publish builds.

Code

.bazelrc.remote[67]

+build:rbe-ci --manager=stub

Evidence

The ordinary CI workflow runs ci-build.sh, whose release-artifact build uses --config=rbe-ci
without an override. That configuration now selects the stub manager aliases; the Java manager
artifact is among the tagged release artifacts. Only the separate release-preparation script
restores --manager=download.

.github/workflows/ci-rbe.yml[43-60]
scripts/github-actions/ci-build.sh[27-31]
common/manager/BUILD.bazel[13-19]
java/src/org/openqa/selenium/manager/BUILD.bazel[12-23]
scripts/github-actions/prepare-release.sh[30-31]

Agent prompt

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

## Issue description
Ordinary RBE CI builds release artifacts with stubbed managers, so it does not validate the package configuration used for publishing.
## Fix Focus Areas
- scripts/github-actions/ci-build.sh[27-31]
- .bazelrc.remote[64-67]
## Recommended Fix
Keep stub mode for the RBE test command, but pass `--manager=download` to the release-artifact build, or otherwise add a CI build of those artifacts with downloaded managers.

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

---

Results up to commit 7c97437 🧠 Deep

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

1. Windows stub-mode test runs pass by skipping ✓ Resolved

Description

On Windows, the stub-selenium-manager-windows filegroup is marked @platforms//:incompatible, so
every binding library, package and browser test that depends on
//common/manager:selenium-manager-windows becomes incompatible too. Bazel reports an error only
for targets named explicitly; with a wildcard such as bazel test --manager=stub //... it skips
incompatible targets without reporting them, so a Windows run can end green with none of the browser
tests executed. That contradicts the commit's stated aim of failing at build time.

Code

common/manager/BUILD.bazel[R80-86]

+filegroup(
+    name = "stub-selenium-manager-windows",
+    srcs = ["stub-selenium-manager"],
+    target_compatible_with = select({
+        "//common:windows": ["@platforms//:incompatible"],
+        "//conditions:default": [],
+    }),

Evidence

The filegroup's target_compatible_with returns @platforms//:incompatible under
//common:windows, and incompatibility spreads to every target that depends on it. All bindings
consume the windows alias; .NET's webdriver-pack and manager-windows are examples. Bazel's
documented behaviour is to skip incompatible targets that a wildcard pattern matches and to error
only on targets requested explicitly. As a result, //... runs on Windows silently skip the tests
instead of failing.

common/manager/BUILD.bazel[44-50]
common/manager/BUILD.bazel[79-87]
dotnet/src/webdriver/BUILD.bazel[187-207]
common/BUILD.bazel[71-76]

Agent prompt

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

## Issue description
With `--manager=stub` on a Windows host, `stub-selenium-manager-windows` is marked incompatible. Every dependent target is then skipped silently when tests are selected with a wildcard such as `//...`, so the run passes without executing any tests.

## Fix Focus Areas
- common/manager/BUILD.bazel[79-87]

## Recommended Fix
Make the misconfiguration a hard error instead of an incompatibility. One option: in the `selenium-manager-windows` alias, select on a combined config (`selects.config_setting_group` from bazel_skylib, matching `//common:manager_stub` AND `//common:windows`) and add `no_match_error` so analysis fails. Another option: use a small rule that calls `fail("--manager=stub is not supported on Windows hosts; use --manager=download")` when built on Windows. Either way, a wildcard build should fail instead of skipping the targets.

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

---

Results up to commit cbc55a4 🧠 Deep

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

1. Host packages omit dependency notices ✗ Dismissed

Description

The manager_host branch of selenium-manager-notice substitutes a placeholder for the third-party
notices even though that mode bundles a locally compiled Selenium Manager. Building a Java manager
artifact or .NET WebDriver package with --manager=host therefore pairs a real binary with a notice
file that contains none of its dependency notices; the corresponding SBOM is empty as well.

Code

common/manager/BUILD.bazel[64]

+        "//common:manager_host": ":stub-selenium-manager-THIRD-PARTY-NOTICES.txt",

Evidence

Host mode selects Rust manager aliases, which resolve to the locally compiled binary on the matching
platform. The snapshot workflow generates notices from its Rust dependencies, but the new host-mode
alias instead selects a two-line placeholder; both Java and .NET package that alias alongside the
manager binary.

common/manager/BUILD.bazel[13-18]
rust/BUILD.bazel[80-93]
rust/about.toml[1-28]
.github/workflows/sm-snapshot.yml[297-303]
common/manager/BUILD.bazel[53-67]
common/manager/stub-selenium-manager-THIRD-PARTY-NOTICES.txt[1-2]
common/manager/stub-selenium-manager.cdx.json[5-10]
java/src/org/openqa/selenium/manager/BUILD.bazel[8-22]
dotnet/src/webdriver/BUILD.bazel[194-208]

Agent prompt

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

## Issue description
Host-mode packages bundle a compiled Selenium Manager but substitute empty SBOM and third-party notices files.
## Fix Focus Areas
- common/manager/BUILD.bazel[53-67]
- rust/BUILD.bazel[113-146]
## Recommended Fix
Select metadata generated from the Rust dependency tree for `--manager=host`, or otherwise provide accurate third-party notices and an SBOM for the compiled binary. Keep placeholder metadata exclusive to configurations that bundle only stubs.

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

---

2. CI re-analyses the whole repo for the package build ✗ Dismissed

Description

test:rbe-ci --manager=stub applies the flag only to bazel test, so the `bazel build
--config=rbe-ci --build_tag_filters=release-artifact //... step that ci-build.sh` runs next uses a
different //common:manager value. Bazel throws away the analysis cache whenever a build option
changes between commands on the same server. That means every non-release-preparation CI run
analyses //... a second time, and the package build gets no reuse from the analysis the test step
just did.

Code

.bazelrc.remote[67]

+test:rbe-ci --manager=stub

Evidence

ci-build.sh runs bazel test --config=rbe-ci ... //... and then, in the same Bazel server, `bazel
build --config=rbe-ci --build_tag_filters=release-artifact //...`. Because the flag sits under
test:, the first command uses --manager=stub and the second uses the default download.
Changing a build option, Starlark flags included, makes Bazel discard its analysis cache.

scripts/github-actions/ci-build.sh[22-31]
.bazelrc.remote[64-67]

Agent prompt

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

## Issue description
`test:rbe-ci --manager=stub` makes the test step and the next `bazel build --config=rbe-ci` release-artifact step use different `//common:manager` values. Bazel then discards the analysis cache and analyses `//...` again.

## Fix Focus Areas
- .bazelrc.remote[67-67]
- scripts/github-actions/ci-build.sh[22-31]

## Recommended Fix
If the extra analysis time is acceptable, keep the split and add a comment saying it is intentional. If not, move the release-artifact build into its own Bazel output base or server (for example with a separate `--output_base`), or run it with an explicit flag ordering that keeps the analysis cache. The package build must keep using the downloaded manager.

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

---