Conversation
|
Warning Review limit reached
More reviews will be available in 1 minute and 55 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughEnables Android E2E CI jobs, expands BrowserStack Android codegen tasks, updates PingTestRunner scripts/dependencies and Android packaging/includes, and pins/simplifies Xcode selection and simulator resolution in the iOS CI workflow. ChangesAndroid E2E Testing Enablement
iOS Build Tooling Update
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-and-test-ios.yml:
- Around line 116-124: The current extraction of AVAILABLE using awk '/Available
destinations/,/Ineligible destinations/' | head -n -1 is non-portable on macOS;
update the pipeline that sets AVAILABLE (which reads DESTINATIONS) to use a
single awk invocation that prints lines after the "Available destinations"
header and stops at "Ineligible destinations" if present (i.e., use awk state
flags to skip the two header/footer lines and tolerate a missing "Ineligible
destinations"), so DEST_LINE (which greps DESTINATIONS/AVAILABLE for
"platform:iOS Simulator" and "name:iPhone") receives the correct block on BSD
head.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d896e12c-3403-4dc2-b2f2-a1ff5b7b6e84
⛔ Files ignored due to path filters (2)
.yarn/install-state.gzis excluded by!**/.yarn/**,!**/*.gzyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (5)
.github/workflows/browserstack-e2e-android.yml.github/workflows/build-and-test-ios.yml.github/workflows/ci.yml.github/workflows/e2e-tests.ymlPingTestRunner/package.json
💤 Files with no reviewable changes (2)
- .github/workflows/e2e-tests.yml
- .github/workflows/ci.yml
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-and-test-ios.yml:
- Around line 87-88: Replace the hard-coded xcode-select step ("Select Xcode
version") with the runtime-aware "Resolve Xcode version" logic used in the
e2e-tests workflow (or add an equivalent preflight) so the job verifies a
provisioned iOS simulator runtime before switching Xcode; specifically, reuse
the resolver that determines an Xcode installation with matching simulator
runtimes (the same step that precedes "Resolve simulator destination") and run
that check before calling xcode-select, and then remove or narrow the use of
job-level continue-on-error so simulator/setup failures aren’t silently masked.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3da92390-5376-4a9f-a296-3acc5021cb6c
⛔ Files ignored due to path filters (2)
.yarn/install-state.gzis excluded by!**/.yarn/**,!**/*.gzyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (7)
.github/workflows/browserstack-e2e-android.yml.github/workflows/build-and-test-ios.yml.github/workflows/ci.yml.github/workflows/e2e-tests.ymlPingTestRunner/android/app/build.gradlePingTestRunner/android/settings.gradlePingTestRunner/package.json
💤 Files with no reviewable changes (1)
- .github/workflows/e2e-tests.yml
🚧 Files skipped from review as they are similar to previous changes (3)
- .github/workflows/ci.yml
- .github/workflows/browserstack-e2e-android.yml
- PingTestRunner/android/settings.gradle
| - name: Select Xcode version | ||
| run: sudo xcode-select -s "${{ env.XCODE_RESOLVED_PATH }}" && /usr/bin/xcodebuild -version | ||
| run: sudo xcode-select -s /Applications/Xcode_${{ env.XCODE_VERSION }}.app && /usr/bin/xcodebuild -version |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate and print the relevant sections for the iOS workflow and the shared resolver
FILE1=".github/workflows/build-and-test-ios.yml"
FILE2=".github/workflows/e2e-tests.yml"
echo "=== $FILE1 (around select Xcode version + simulator destination) ==="
# Print around the referenced line numbers with some buffer
nl -ba "$FILE1" | sed -n '60,140p'
echo
echo "=== $FILE2 (around Xcode/simulator resolver) ==="
nl -ba "$FILE2" | sed -n '35,120p'
echo
echo "=== $FILE1 (full job blocks with continue-on-error) ==="
# Show lines containing continue-on-error and any "Resolve simulator destination" step name
rg -n "continue-on-error|Resolve simulator destination|xcode-select|Xcode_|xcodebuild -showdestinations" "$FILE1" || trueRepository: ForgeRock/ping-react-native-sdk
Length of output: 240
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE1=".github/workflows/build-and-test-ios.yml"
FILE2=".github/workflows/e2e-tests.yml"
echo "=== $FILE1 (around select Xcode version + simulator destination) ==="
awk 'NR>=60 && NR<=140 {printf "%d:%s\n", NR, $0}' "$FILE1" | sed -n '1,200p'
echo
echo "=== $FILE2 (around Xcode/simulator resolver) ==="
awk 'NR>=35 && NR<=120 {printf "%d:%s\n", NR, $0}' "$FILE2" | sed -n '1,200p'
echo
echo "=== $FILE1 (locations of key steps/flags) ==="
rg -n "continue-on-error|Resolve simulator destination|xcode-select|Xcode_|xcodebuild -showdestinations" "$FILE1" || trueRepository: ForgeRock/ping-react-native-sdk
Length of output: 9971
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE1=".github/workflows/build-and-test-ios.yml"
awk 'NR>=1 && NR<=260 {printf "%d:%s\n", NR, $0}' "$FILE1" | sed -n '1,260p'Repository: ForgeRock/ping-react-native-sdk
Length of output: 9302
🌐 Web query:
GitHub Actions job-level continue-on-error support semantics
💡 Result:
GitHub Actions supports continue-on-error at the job level via jobs.<job_id>.continue-on-error (boolean / expression). When set to true, failures in that job don’t fail the overall workflow run, but they do still mark the job as failed (so you’ll typically see a red X in the UI) and any steps inside the job still behave as usual unless you also use step-level continue-on-error. Semantics to know 1) What changes at the job level - jobs.<job_id>.continue-on-error: true prevents the job from failing the overall workflow run; i.e., downstream workflows/jobs that depend on the run won’t be blocked the same way as with a hard failure. [1] - Even with job-level continue-on-error enabled, the job itself is still considered failed in the job’s own conclusion/visual status. [2] 2) How step expressions like failure behave - With job-level continue-on-error, a failed step can still trigger conditions like if: ${{ failure }} in subsequent steps because the step actually failed (even though the job is allowed to continue). This is consistent with reported behavior: the workflow runs subsequent steps, but the job is still marked as an overall failure. [3] 3) Job status vs workflow status - There’s a distinction between “job did not fail the workflow” and “job is green.” An observed outcome is: subsequent steps can run, but the job will be an overall failure (red X), even though the workflow may be allowed to proceed. [2] 4) Nested/indirect continue-on-error limitations - continue-on-error at a higher level does not necessarily suppress failures from deeply nested actions (e.g., action calling another action calling a node action). This means job-level continue-on-error may not “mask” all underlying tool failures across all nesting layers. [4] Practical guidance - Use job-level continue-on-error when you want the workflow to keep going even if that entire job encounters an error, but you still want the job to be visible as failed for diagnostics. [1][2] - If you need specific steps to not trigger conditional logic (or you want to control exactly which later steps run), consider step-level continue-on-error and/or explicit conditions based on step outcomes rather than relying on failure alone. The step-triggered behavior is documented/observed under job-level continue-on-error. [3] Example (job-level) jobs: test: runs-on: ubuntu-latest continue-on-error: true steps: - run: exit 1 - run: echo "This runs, but the job is still failed"
Citations:
- 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 2: https://www.kenmuse.com/blog/how-to-handle-step-and-job-errors-in-github-actions/
- 3: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
- 4:
continue-on-errorin an action doesn't suppress an error from a node action called by an action it calls actions/runner#3510
Keep the runtime-compatible Xcode resolver (avoid pinned hard-switch) in iOS workflow
.github/workflows/build-and-test-ios.ymlhard-switches to/Applications/Xcode_${{ env.XCODE_VERSION }}.app(lines 87-88) but doesn’t use the runtime-aware “Resolve Xcode version” logic from.github/workflows/e2e-tests.yml.- If that pinned Xcode lacks a provisioned iOS simulator runtime, “Resolve simulator destination” (lines 114-127) can fail with “No eligible iPhone simulator found”, preventing the later iOS test steps from running; with job-level
continue-on-error: true(line 29), the overall workflow run can still succeed even when iOS tests never execute. - Reuse the existing resolver (or equivalent preflight verifying simulator runtime availability) before running
xcode-select, and avoid relying oncontinue-on-errorto mask simulator/setup failures when tests are expected to run.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build-and-test-ios.yml around lines 87 - 88, Replace the
hard-coded xcode-select step ("Select Xcode version") with the runtime-aware
"Resolve Xcode version" logic used in the e2e-tests workflow (or add an
equivalent preflight) so the job verifies a provisioned iOS simulator runtime
before switching Xcode; specifically, reuse the resolver that determines an
Xcode installation with matching simulator runtimes (the same step that precedes
"Resolve simulator destination") and run that check before calling xcode-select,
and then remove or narrow the use of job-level continue-on-error so
simulator/setup failures aren’t silently masked.
1 participant
Summary by CodeRabbit