Skip to content

Conversation

@titusfortner
Copy link
Member

@titusfortner titusfortner commented Jan 6, 2026

User description

🔗 Related Issues

Uses #16840 for ruby

💥 What does this PR do?

  • Ruby should rerun failures with debug enabled

Here's an example of it working:
https://github.com/SeleniumHQ/selenium/actions/runs/20821698874/job/59812871900?pr=16858

  • Targets fail
  • Failing targegts are added to build/failures/_run1.txt (nested in build directory since it is in .gitignore)
  • Targets are rerun with SE_DEBUG=true (output may exceed what GitHub will display in console)
  • Rerun failures are stored in build/failures/_run2.txt
  • The logs for failures are copied into build/failures directory and renamed to the target name
  • Failed logs are zipped and made available for download along with _run files

PR Type

Tests, Enhancement


Description

  • Add rerun-with-debug flag to Ruby test workflows

  • Intentionally break tests to verify rerun mechanism works

  • Reduce flaky_test_attempts from 3 to 2 in local/remote tests

  • Clean up whitespace in CI workflow file


Diagram Walkthrough

flowchart LR
  A["Ruby Test Workflows"] -->|"Add rerun-with-debug flag"| B["Unit/Local/Remote Tests"]
  B -->|"Reduce attempts 3→2"| C["Flaky Test Handling"]
  D["Test Expectations"] -->|"Intentional failures"| E["Verify Rerun Works"]
Loading

File Walkthrough

Relevant files
Tests
element_spec.rb
Intentional test failures for rerun verification                 

rb/spec/integration/selenium/webdriver/element_spec.rb

  • Modified multiple test expectations to intentionally fail
  • Changed expected values to 'nope' or 'Nope' in 6 test cases
  • Tests cover key_reporter, file upload, and element properties
  • Purpose is to verify the rerun mechanism works correctly
+7/-7     
Configuration changes
ci-ruby.yml
Configure Ruby CI for debug rerun on failures                       

.github/workflows/ci-ruby.yml

+9/-6     

@selenium-ci selenium-ci added C-rb Ruby Bindings B-build Includes scripting, bazel and CI integrations labels Jan 6, 2026
@qodo-code-review
Copy link
Contributor

qodo-code-review bot commented Jan 6, 2026

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢
No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡
🎫 #1234
🔴 Ensure that clicking a link whose href contains JavaScript (e.g., javascript:...) triggers
the JavaScript when using click() (regression from Selenium 2.47.1 to 2.48.x),
specifically observed in Firefox 42.
Provide/maintain a test case demonstrating the expected alert behavior for the provided
reproduction.
🟡
🎫 #5678
🔴 Address the "Error: ConnectFailure (Connection refused)" that occurs when instantiating
multiple ChromeDriver instances (Ubuntu 16.04, Selenium 3.9.0, Chrome/ChromeDriver
65/2.35).
Provide guidance or code changes to prevent/recover from the repeated instantiation
failure scenario.
Codebase Duplication Compliance
Codebase context is not defined

Follow the guide to enable codebase context checks.

Custom Compliance
🟢
Generic: Comprehensive Audit Trails

Objective: To create a detailed and reliable record of critical system actions for security analysis
and compliance.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Meaningful Naming and Self-Documenting Code

Objective: Ensure all identifiers clearly express their purpose and intent, making code
self-documenting

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Robust Error Handling and Edge Case Management

Objective: Ensure comprehensive error handling that provides meaningful context and graceful
degradation

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Secure Error Handling

Objective: To prevent the leakage of sensitive system information through error messages while
providing sufficient detail for internal debugging.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Secure Logging Practices

Objective: To ensure logs are useful for debugging and auditing without exposing sensitive
information like PII, PHI, or cardholder data.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Security-First Input Validation and Data Handling

Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent
vulnerabilities

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

  • Update
Compliance status legend 🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

@qodo-code-review
Copy link
Contributor

qodo-code-review bot commented Jan 6, 2026

PR Code Suggestions ✨

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Impact
Possible issue
Restore correct test expectations
Suggestion Impact:The commit updated the failing test expectation in element_spec.rb from expecting 'Nope' to expecting 'Hello', matching the suggested fix (and also corrected several other 'nope' expectations in the same file).

code diff:

         key_reporter.send_keys([:shift, 'h'], 'ello')
-        expect(key_reporter.attribute('value')).to eq('Nope')
+        expect(key_reporter.attribute('value')).to eq('Hello')
       end

Revert the intentionally failing test expectation in element_spec.rb to its
correct value to ensure tests pass.

rb/spec/integration/selenium/webdriver/element_spec.rb [132]

-expect(key_reporter.attribute('value')).to eq('Nope')
+expect(key_reporter.attribute('value')).to eq('Hello')

[Suggestion processed]

Suggestion importance[1-10]: 9

__

Why: This is a critical suggestion as merging the intentionally failing test would break the build on the main branch.

High
General
Define rerun-with-debug input

Ensure the reusable bazel.yml workflow is updated to accept and process the
rerun-with-debug input parameter.

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

-rerun-with-debug: true
+# In .github/workflows/bazel.yml:
+on:
+  workflow_call:
+    inputs:
+      rerun-with-debug:
+        description: "Enable rerun with debug logs"
+        required: false
+        type: boolean
 
+# Then use it in the test step:
+- name: Run Bazel tests
+  run: |
+    bazel test \
+      --keep_going \
+      --rerun_with_debug=${{ inputs.rerun-with-debug }} \
+      ...
+

[To ensure code accuracy, apply this suggestion manually]

Suggestion importance[1-10]: 7

__

Why: This suggestion correctly points out that for the rerun-with-debug parameter to work, the called reusable workflow (bazel.yml) must be updated to accept it, which is not part of this PR.

Medium
  • Update

@titusfortner titusfortner changed the title [build] Set Ruby tests to rerun when failing [rb] Set Ruby tests to rerun when failing Jan 6, 2026
@titusfortner titusfortner force-pushed the rb_rerun branch 2 times, most recently from 2f81c79 to 092e1b5 Compare January 8, 2026 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

B-build Includes scripting, bazel and CI integrations C-rb Ruby Bindings Review effort 3/5

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants