Update browser tag filters to stable versions

• Update os-sensitive tag filter from beta browsers to stable browsers
• Update se-manager tag filter from beta browsers to stable browsers
• Changes affect smoke test execution to use stable Chrome, Firefox, Edge, Safari

rb/spec/tests.bzl

Add conditional skip for pending tests

• Modify pending disposition check to skip when SKIP_PENDING environment variable is set
• Allows conditional skipping of pending tests during CI execution

rb/spec/unit/selenium/webdriver/guard_spec.rb

Remove lint test target and convert to binary

• Remove rb_test import from rules_ruby
• Remove lint rb_test target definition
• Convert lint to binary target for manual execution

rb/BUILD.bazel

Description

workflow_dispatch introduces a user-provided targets input that is later interpolated into a
shell command without validation/quoting, enabling command injection and unsafe argument splitting.
This violates the CI/script hardening requirement and can lead to unexpected command execution or
incorrect Bazel invocation.

Code

.github/workflows/ci-ruby.yml[R10-15]

  workflow_dispatch:
+    inputs:
+      targets:
+        description: Specify Bazel Targets
+        type: string
+        default: '//rb/...'

Evidence

PR Compliance ID 14 requires safe argument handling in CI scripts. The PR adds a manually-supplied
targets input and later expands ${{ inputs.targets }} directly into a shell command, which is
unsafe because the expanded text can be interpreted by the shell as additional commands/flags.

.github/workflows/ci-ruby.yml[10-15]
.github/workflows/ci-ruby.yml[73-80]
Best Practice: Learned patterns

Agent prompt

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

## Issue description
A `workflow_dispatch` string input (`inputs.targets`) is user-controlled and later inserted directly into a `bazel test` shell command, allowing shell metacharacters (e.g., `;`, `&&`) to be interpreted as commands.

## Issue Context
This workflow now accepts `targets` via manual dispatch. The value is used in the `os-tests` job’s `run` script, so it must be handled as data (arguments) rather than executable shell text.

## Fix Focus Areas
- .github/workflows/ci-ruby.yml[10-15]
- .github/workflows/ci-ruby.yml[73-80]

## Suggested approach
- Read `inputs.targets` into a variable inside quotes.
- Split into a bash array safely (e.g., `read -r -a targets_arr <<< "$targets"`).
- Invoke Bazel with `"${targets_arr[@]}"` so each target is a separate argument and shell metacharacters are not executed.
- Optionally validate that each entry matches expected Bazel target patterns (e.g., starts with `//`).

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

Description

The Windows os-tests job uses --test_tag_filters=edge,edge-remote,unit,skip-rbe,-ie, but IE
remote targets are tagged ie-remote (not ie) and also include skip-rbe, so they can still be
selected and executed on Windows despite the -ie exclusion.

Code

.github/workflows/ci-ruby.yml[59]

+            tag-filters: edge,edge-remote,unit,skip-rbe,-ie

Evidence

The workflow’s Windows tag filter includes skip-rbe and only excludes ie. In the Ruby test rule
generator, IE is defined with the skip-rbe tag, and remote tests are tagged as {browser}-remote
while inheriting the browser tags. Also, some integration tests do not override the default
browsers=BROWSERS.keys(), so IE/IE-remote targets exist and are eligible for selection.

.github/workflows/ci-ruby.yml[54-62]
rb/spec/tests.bzl[130-141]
rb/spec/tests.bzl[170-171]
rb/spec/tests.bzl[195-215]
rb/spec/integration/selenium/webdriver/BUILD.bazel[30-37]

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 `os-tests` matrix entry tries to exclude IE by adding `-ie`, but IE remote targets use the tag `ie-remote` and inherit `skip-rbe`, so they still match the positive filters.

### Issue Context
`rb_integration_test` generates both local and `*-remote` test targets, and remote targets inherit the browser-specific tag list (including `skip-rbe` for IE).

### Fix Focus Areas
- .github/workflows/ci-ruby.yml[57-60]

### Suggested fix
Update the Windows `tag-filters` to also exclude the remote IE tag, e.g.:
- `edge,edge-remote,unit,skip-rbe,-ie,-ie-remote`

(Alternatively, remove `skip-rbe` from the Windows include list if it is not intended to pull in unrelated `skip-rbe` tests.)

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

Description

In ci.yml, process_binding assigns lang_targets via a pipeline containing grep; when there are no
matching Ruby targets, grep exits non-zero and can fail the entire “Read targets” step instead of
simply producing no rb_targets output.

Code

.github/workflows/ci.yml[R89-94]

+          process_binding() {
+            local pattern=$1 tag=$2
+            local lang_targets
+            lang_targets=$(echo "$targets" | tr ' ' '\n' | grep -E "^${pattern}[:/]" | tr '\n' ' ' | sed 's/ *$//')
+            [ -n "$lang_targets" ] && echo "${tag}_targets=$lang_targets" >> "$GITHUB_OUTPUT"
+          }

Evidence

The process_binding() function uses a grep -E pipeline to compute lang_targets (line 92). If
no targets match ^//rb[:/], grep returns non-zero; without || true this can fail the step
rather than just leaving rb_targets unset.

.github/workflows/ci.yml[81-100]

Agent prompt

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

### Issue description
`process_binding()` uses `grep` inside a command substitution without guarding for the “no matches” exit code. When no Ruby targets exist, this can terminate the step early and fail CI.

### Issue Context
The workflow should continue and simply omit `rb_targets` when there are no matching targets.

### Fix Focus Areas
- .github/workflows/ci.yml[81-100]

### Suggested fix
- Make the pipeline tolerant of no matches, e.g. append `|| true` to the *whole* pipeline, or use `grep ... || :`.
 - Example:
   - `lang_targets=$(echo "$targets" | tr ' ' '\n' | grep -E "^${pattern}[:/]" | tr '\n' ' ' | sed 's/ *$//' || true)`
- Consider switching `echo` to `printf '%s\n' "$targets"` to avoid echo edge cases.

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

Description

ci-ruby.yml uses ${{ inputs.targets }} in the os-tests Bazel command, but targets is only
defined under workflow_call; a manual workflow_dispatch run can expand to an empty target list
and cause bazel test to fail.

Code

.github/workflows/ci-ruby.yml[R74-76]

+        --test_tag_filters=${{ matrix.tag-filters }}
+        ${{ inputs.targets }}
+        || { code=$?; [ "$code" -eq 4 ] && exit 0; exit "$code"; }

Evidence

The workflow defines targets only for workflow_call (lines 4-9) but the os-tests run command
always interpolates ${{ inputs.targets }} (line 75).

.github/workflows/ci-ruby.yml[3-11]
.github/workflows/ci-ruby.yml[47-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
`os-tests` references `inputs.targets`, but `targets` is only declared for `workflow_call`. For `workflow_dispatch` runs, this input is not defined, so the Bazel command may receive no explicit targets.

### Issue Context
The workflow declares `workflow_dispatch:` with no inputs, but still relies on `inputs.targets`.

### Fix Focus Areas
- .github/workflows/ci-ruby.yml[3-11]
- .github/workflows/ci-ruby.yml[47-76]

### Suggested fix
Add `workflow_dispatch.inputs.targets` mirroring the `workflow_call` input (same default `//rb/...`), or change the command to fall back to `//rb/...` when `inputs.targets` is empty.

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

Description

The os-tests job treats bazel test exit code 4 as success, which can mask misconfiguration
(e.g., filters producing “no tests found”) and allow CI to go green without running any Ruby tests.
This violates the requirement to avoid error-swallowing constructs in CI/scripts that hide failures.

Code

.github/workflows/ci-ruby.yml[R74-76]

+        --test_tag_filters=${{ matrix.tag-filters }}
+        ${{ inputs.targets }}
+        || { code=$?; [ "$code" -eq 4 ] && exit 0; exit "$code"; }

Evidence

PR Compliance ID 15 forbids error-swallowing in CI/scripts that can hide failures. The added shell
handler explicitly exits 0 when bazel test returns code 4, masking “no tests found”
conditions.

.github/workflows/ci-ruby.yml[74-76]
Best Practice: Learned patterns

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 `os-tests` Bazel invocation converts exit code `4` into success (`exit 0`). This can hide “no tests found” situations caused by incorrect target selection or tag filters, resulting in false-green CI.

## Issue Context
`bazel test` exit code `4` typically indicates that no tests were executed. Treating this as success in PR CI can allow Ruby changes to merge without test coverage.

## Fix Focus Areas
- .github/workflows/ci-ruby.yml[74-76]

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

Description

The macOS os-tests job includes skip-rbe as a positive --test_tag_filters value, which matches
safari-preview tests because they carry the skip-rbe tag; the workflow only performs Safari setup
when inputs.browser == 'safari', so safari-preview targets may run without intended setup.

Code

.github/workflows/ci-ruby.yml[R60-62]

+          - os: macos
+            browser: safari
+            tag-filters: safari,safari-remote,unit,skip-rbe,-lint

Evidence

macOS tag filters include skip-rbe. In Ruby test definitions, safari-preview is tagged with
skip-rbe and is macOS-compatible, and safari integration BUILD files explicitly request
safari-preview targets. Meanwhile, the runner setup only enables Safari when the workflow input is
exactly safari.

.github/workflows/ci-ruby.yml[47-76]
rb/spec/tests.bzl[142-167]
rb/spec/integration/selenium/webdriver/safari/BUILD.bazel[3-13]
.github/workflows/bazel.yml[265-267]

Agent prompt

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

### Issue description
`skip-rbe` is included as a positive tag filter on macOS. Ruby safari-preview targets are tagged `skip-rbe`, so they can be selected even though the job is intended to run Safari.

### Issue Context
- `safari-preview` browser definition includes `skip-rbe` and is macOS-compatible.
- Some integration specs explicitly generate both `safari` and `safari-preview` targets.
- GitHub Actions setup only enables safaridriver when `inputs.browser == 'safari'`.

### Fix Focus Areas
- .github/workflows/ci-ruby.yml[52-63]

### Suggested fix
- Remove `skip-rbe` from macOS `tag-filters`, or
- Add an explicit exclusion: `-safari-preview,-safari-preview-remote` (and `-safari-preview-bidi` if applicable).
- Optionally, if you *do* want safari-preview coverage, add explicit setup steps and set `browser: safari-preview` so bazel.yml can configure it.

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

Description

ci-ruby.yml sets matrix.browser: true (boolean) and passes it into bazel.yml where browser is
declared as a string input; this can break reusable-workflow input validation or lead to unexpected
conditional behavior (inputs.browser != '').

Code

.github/workflows/ci-ruby.yml[R54-59]

+          - os: ubuntu
+            browser: true
+            tag-filters: unit,skip-rbe,-lint
+          - os: windows
+            browser: true
+            tag-filters: edge,edge-remote,unit,skip-rbe,-ie,-lint

Evidence

ci-ruby sets browser: true in the matrix (boolean) and forwards it as `browser: ${{ matrix.browser
}}. bazel.yml declares browser as a string input and uses it in conditions like inputs.browser
!= ''`, so passing a boolean is unsafe.

.github/workflows/ci-ruby.yml[52-66]
.github/workflows/bazel.yml[19-28]
.github/workflows/bazel.yml[252-267]

Agent prompt

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

### Issue description
`matrix.browser` is set to YAML boolean `true` for ubuntu/windows, then forwarded to reusable workflow input `browser` which is typed as `string`. This risks workflow-call validation errors and also changes behavior of steps gated on `inputs.browser != ''`.

### Issue Context
The called workflow declares `browser` as `type: string`.

### Fix Focus Areas
- .github/workflows/ci-ruby.yml[52-66]
- .github/workflows/bazel.yml[19-28]

### Suggested fix
- Change `browser: true` to a string value:
 - If you want “no specific browser but enable UI setup”, use `browser: 'enabled'` (string) and update bazel.yml docs accordingly.
 - If you actually intend Edge on Windows, set `browser: 'edge'`.
 - If Ubuntu is unit-only, set `browser: ''` and adjust tag filters accordingly.
- Keep macOS as `browser: safari` for safaridriver enablement.

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

Description

The ActionBuilder integration tests it 'presses pointer twice' and it 'sends keys to element'
were changed to run unconditionally, no longer excluding Safari/Safari Preview, which can cause
cross-browser CI failures when Actions/double-click or Actions+sendKeys behavior is not consistently
supported by a given browser/driver. These tests should be conditionally gated/skipped based on
runtime/browser feature support where unsupported.

Code

rb/spec/integration/selenium/webdriver/action_builder_spec.rb[162]

+        it 'presses pointer twice' do

Evidence

PR Compliance ID 13 requires guarding tests by runtime/browser feature support to avoid
cross-environment failures. In rb/spec/integration/selenium/webdriver/action_builder_spec.rb, the
modified tests at lines 41 and 162 are now unconditional (run for all browsers), while nearby
ActionBuilder/double-click-related tests in the same file still explicitly exclude Safari/Safari
Preview via except: {browser: %i[safari safari_preview]}, indicating there is known or expected
variance in support that these two tests should also account for.

rb/spec/integration/selenium/webdriver/action_builder_spec.rb[162-168]
rb/spec/integration/selenium/webdriver/action_builder_spec.rb[170-179]
rb/spec/integration/selenium/webdriver/action_builder_spec.rb[41-50]
rb/spec/integration/selenium/webdriver/action_builder_spec.rb[28-29]
Best Practice: Learned patterns

Agent prompt

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

## Issue description
Two browser-sensitive ActionBuilder integration tests (`it 'presses pointer twice'` and `it 'sends keys to element'`) were changed to run unconditionally. If Safari/Safari Preview (or another CI browser/driver) does not reliably support the specific Actions double-click / pointer behavior or Actions+send_keys behavior under test, this can introduce cross-browser CI failures.

## Issue Context
PR Compliance ID 13 requires gating tests by runtime/browser feature support to prevent cross-environment failures. Other ActionBuilder tests in the same spec file remain gated with `except: {browser: %i[safari safari_preview]}`, and an adjacent double-click equivalence test still excludes Safari/Safari Preview, implying known incompatibility or flakiness that should be handled consistently.

## Fix Focus Areas
- rb/spec/integration/selenium/webdriver/action_builder_spec.rb[41-50]
- rb/spec/integration/selenium/webdriver/action_builder_spec.rb[162-179]

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

Description

os-tests tag filters do not include chrome or firefox, but Ruby integration tests are tagged
with their browser name (e.g., chrome, firefox); if the affected targets include those tests,
--test_tag_filters can filter them out so they never run in ci-ruby despite being affected.

Code

.github/workflows/ci-ruby.yml[R53-62]

+        include:
+          - os: ubuntu
+            browser: true
+            tag-filters: unit,skip-rbe,-lint
+          - os: windows
+            browser: true
+            tag-filters: edge,edge-remote,unit,skip-rbe,-ie,-lint
+          - os: macos
+            browser: safari
+            tag-filters: safari,safari-remote,unit,skip-rbe,-lint

Evidence

Ruby integration tests are tagged with their browser name (local) and ${browser}-remote (remote).
ci-ruby os-tests only includes edge/safari tags, so chrome/firefox-tagged integration tests can be
filtered out even when passed via inputs.targets.

.github/workflows/ci-ruby.yml[47-76]
rb/spec/tests.bzl[170-215]

Agent prompt

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

### Issue description
`os-tests` uses `--test_tag_filters` that select only edge/safari/unit/skip-rbe (plus exclusions). Ruby integration tests are tagged with `[browser]` and `[browser-remote]`, so affected chrome/firefox tests may be excluded and not exercised on GitHub-hosted OS runners.

### Issue Context
Ruby integration test generation appends the browser tag (e.g., `chrome`) to each test target.

### Fix Focus Areas
- .github/workflows/ci-ruby.yml[47-76]

### Suggested fix
- If you intend to run affected integration tests for chrome/firefox on OS runners, add `chrome,chrome-remote,firefox,firefox-remote` (and beta variants if needed) to the appropriate matrix entries.
- If you intentionally rely on RBE for chrome/firefox coverage, consider documenting that explicitly in the workflow and ensure required CI checks still cover those targets.

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