🧪 [Draft] Running related tests when a page changes #2744
Conversation
Signed-off-by: Shveta Sachdeva <[email protected]>
WalkthroughAdds a Node.js detector, a test-mapping JSON, and a GitHub Actions workflow to detect which Cypress tests relate to files changed in a PR and conditionally run those tests. Changes
Sequence Diagram(s)sequenceDiagram
actor PR as Pull Request
participant GHA as GitHub Actions
participant Detector as get-related-tests.js
participant Git as Git
participant FS as File System
participant Runner as Cypress Runner
PR->>GHA: open/update PR (path filters)
GHA->>Detector: run detection job
Detector->>Git: git diff --name-only base...head (with fork fallback)
Git-->>Detector: changed files
Detector->>FS: read `cypress/test-mapping.json`
FS-->>Detector: mapping data
rect rgb(232,245,233)
Note over Detector: apply rules\n• include defaultTests\n• dev-page detection\n• include changed Cypress tests\n• map models/views -> categories\n• optional glob expansion (--expand)
Detector->>Detector: build TEST_PATTERNS, set should_run_tests
end
Detector-->>GHA: emit test_patterns, should_run_tests
alt should_run_tests == true
GHA->>Runner: run Cypress with --spec=TEST_PATTERNS
Runner-->>GHA: upload artifacts & results
else
Note over GHA: skip test execution
end
GHA->>GHA: publish summary job (patterns & status)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)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: 3
🧹 Nitpick comments (2)
.github/workflows/pr-related-tests.yml (1)
38-48:should_run_testswill always betruewith the current script + mappingBecause
get-related-tests.jsunconditionally addsdefaultTeststo the pattern set whenever it’s invoked,TEST_PATTERNSis never empty. That means this check:if [ -n "$TEST_PATTERNS" ]; then echo "should_run_tests=true" >> $GITHUB_OUTPUT else echo "should_run_tests=false" >> $GITHUB_OUTPUT fiwill always set
should_run_tests=truefor any PR that hits this workflow, andrun-related-testswill never be skipped. The “⏭️ No related tests to run” branch intest-summaryis therefore unreachable.If the intent is to sometimes skip running Cypress (e.g., for mapping-only changes or when no mapping/category matches are found), you’ll need to adjust either:
- the script to only inject
defaultTestswhen at least one mapping/category match is found, or- this logic to derive
should_run_testsfrom something other than “patterns string is non-empty” (e.g., a dedicated flag output from the script)..github/scripts/get-related-tests.js (1)
50-54: Default tests + TEST_PATTERNS semantics and formattingA couple of behavioral/maintenance notes around TEST_PATTERNS:
matchTestsForChangedFilesalways seedstestPatternswithmapping.defaultTests, andmain()also falls back todefaultTestswhenchangedFiles.length === 0. Combined with the workflow logic, this means TEST_PATTERNS is never empty, so the “no related tests” path in the workflow will never trigger. If you ever want a “truly no tests to run” case, you’ll need to either makedefaultTestsconditional or add a separate boolean output that indicates whether any non-default patterns were matched.- The script’s header comment says it outputs a “Space-separated list of test file patterns,” which is accurate, but note that this combines both default and related patterns into one flat string. Any tooling consuming this (like the workflow) should treat it as an opaque string or explicitly normalize separators before feeding it into tools like Cypress (see workflow comment).
- Prettier is currently failing on this file; after finalizing behavior changes, run the repo’s formatter so the CI
format:checkjob passes.Functionally this is fine as-is; these points are mostly about keeping the contract with the workflow clear and avoiding surprises later.
Also applies to: 91-107, 154-159, 167-177
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/scripts/get-related-tests.js(1 hunks).github/test-mapping.json(1 hunks).github/workflows/pr-related-tests.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2694
File: .github/workflows/e2e-tier0-push-main.yaml:7-8
Timestamp: 2025-11-13T23:21:33.345Z
Learning: In the tackle2-ui repository, the `.github/workflows/e2e-tier0-push-main.yaml` workflow is specifically designed to trigger only on changes to test code under `cypress/**`. Other separate workflows are responsible for running cypress tests when application code outside of `cypress/` changes. This separation of concerns is intentional.
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2656
File: cypress/package.json:8-8
Timestamp: 2025-10-17T16:41:30.776Z
Learning: In the `cypress/package.json` file of the tackle2-ui repository, the npm scripts run with the current working directory set to `cypress/`, so relative paths in those scripts are resolved from the cypress folder, not the repository root.
📚 Learning: 2025-11-13T23:21:33.345Z
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2694
File: .github/workflows/e2e-tier0-push-main.yaml:7-8
Timestamp: 2025-11-13T23:21:33.345Z
Learning: In the tackle2-ui repository, the `.github/workflows/e2e-tier0-push-main.yaml` workflow is specifically designed to trigger only on changes to test code under `cypress/**`. Other separate workflows are responsible for running cypress tests when application code outside of `cypress/` changes. This separation of concerns is intentional.
Applied to files:
.github/workflows/pr-related-tests.yml.github/scripts/get-related-tests.js.github/test-mapping.json
📚 Learning: 2025-10-17T16:41:30.776Z
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2656
File: cypress/package.json:8-8
Timestamp: 2025-10-17T16:41:30.776Z
Learning: In the `cypress/package.json` file of the tackle2-ui repository, the npm scripts run with the current working directory set to `cypress/`, so relative paths in those scripts are resolved from the cypress folder, not the repository root.
Applied to files:
.github/scripts/get-related-tests.js.github/test-mapping.json
🪛 GitHub Actions: CI (repo level)
.github/scripts/get-related-tests.js
[error] 1-1: Prettier formatting check failed. Run 'npx prettier --write' to fix code style issues in this file. Command that failed: npm run format:check.
🪛 GitHub Actions: PR Related Tests
.github/scripts/get-related-tests.js
[error] 3-3: Command failed: 'node .github/scripts/get-related-tests.js origin/main HEAD > output.txt' due to ES module error: 'require' is not defined. The script is treated as an ES module because the file has a .js extension and package.json has "type": "module".
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build-and-upload-for-global-ci
🔇 Additional comments (1)
.github/test-mapping.json (1)
1-75: Mapping structure looks solid; just ensure globs match actual spec filesThe JSON shape (mappings + defaultTests) aligns with how
.github/scripts/get-related-tests.jsconsumes it, and keys/paths are consistent with the app/test layout. I don’t see structural issues here; just make sure each glob actually matches at least one Cypress spec incypress/e2e/testsas this grows over time.
Signed-off-by: Shveta Sachdeva <[email protected]>
Signed-off-by: Shveta Sachdeva <[email protected]>
sshveta
force-pushed
the
pages_to_tests_mapping
branch
from
b80f8f9 to
0a0654d
Compare
Signed-off-by: Shveta Sachdeva <[email protected]>
sshveta
force-pushed
the
pages_to_tests_mapping
branch
from
a063540 to
b68d39e
Compare
Signed-off-by: Shveta Sachdeva <[email protected]>
sshveta
force-pushed
the
pages_to_tests_mapping
branch
from
337bc66 to
ca860bc
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
.github/workflows/pr-related-tests.yml (2)
52-56: Clarify or remove misleading "Upload test patterns" step.This step echoes the test patterns to a file but doesn't actually upload it as an artifact (no
actions/upload-artifactis used). The file is only accessible within this job and won't persist for debugging. Either rename the step to reflect what it does (e.g., "Log test patterns to file") or add an actual artifact upload if you need to preserve these patterns for troubleshooting.Apply this diff if you want to genuinely upload the patterns:
- name: Upload test patterns if: steps.get-tests.outputs.should_run_tests == 'true' + uses: actions/upload-artifact@v4 + with: + name: test-patterns + path: test-patterns.txt + retention-days: 1 + + - name: Save test patterns to file + if: steps.get-tests.outputs.should_run_tests == 'true' run: | echo "${{ steps.get-tests.outputs.test_patterns }}" > test-patterns.txt cat test-patterns.txt
62-67: Remove or populate the unused matrix strategy.The
matrix.test_group: [related]is a static single value that provides no actual parallelization benefit. The comment on line 65-66 indicates this will be "populated dynamically," but it never is. Either remove the matrix entirely or implement the dynamic population logic if you plan to parallelize test execution.If you don't need matrix parallelization yet:
strategy: fail-fast: false - matrix: - # This will be populated dynamically based on test patterns - # For now, we'll run all detected tests in a single job - test_group: [related]And update the artifact name on line 104:
- name: cypress-results-${{ matrix.test_group }} + name: cypress-results-related.github/scripts/get-related-tests.js (1)
95-109: Clarify or implement the incomplete significant-changes logic.This block detects "significant changes" (to
client/src/,cypress/,package.json,tsconfig) when no dev page mappings are found, but only logs a message without adding any tests. This appears to be incomplete logic.If the intent was to run a broader set of tests for significant changes, implement that. Otherwise, if this is just informational logging, consider removing it to avoid confusion.
If you want to run all tests when significant changes are detected:
if (hasSignificantChanges) { console.log('No specific page mappings found but significant changes detected'); + // Run all available tests for significant changes + testPatterns.add('cypress/e2e/tests/**/*.test.ts'); }Or remove the block entirely if it's not needed:
- // If no specific dev page changes were detected but there are other changes, - // we might want to run all tests (or a broader set) - if (!hasDevPageChanges && testPatterns.size === (mapping.defaultTests?.length || 0)) { - // Check if there are significant changes that warrant running all tests - const hasSignificantChanges = changedFiles.some(file => - file.startsWith('client/src/') || - file.startsWith('cypress/') || - file.includes('package.json') || - file.includes('tsconfig') - ); - - if (hasSignificantChanges) { - console.log('No specific page mappings found but significant changes detected'); - } - }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
cypress/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (3)
.github/scripts/get-related-tests.js(1 hunks).github/test-mapping.json(1 hunks).github/workflows/pr-related-tests.yml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/test-mapping.json
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2694
File: .github/workflows/e2e-tier0-push-main.yaml:7-8
Timestamp: 2025-11-13T23:21:33.345Z
Learning: In the tackle2-ui repository, the `.github/workflows/e2e-tier0-push-main.yaml` workflow is specifically designed to trigger only on changes to test code under `cypress/**`. Other separate workflows are responsible for running cypress tests when application code outside of `cypress/` changes. This separation of concerns is intentional.
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2656
File: cypress/package.json:8-8
Timestamp: 2025-10-17T16:41:30.776Z
Learning: In the `cypress/package.json` file of the tackle2-ui repository, the npm scripts run with the current working directory set to `cypress/`, so relative paths in those scripts are resolved from the cypress folder, not the repository root.
📚 Learning: 2025-11-13T23:21:33.345Z
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2694
File: .github/workflows/e2e-tier0-push-main.yaml:7-8
Timestamp: 2025-11-13T23:21:33.345Z
Learning: In the tackle2-ui repository, the `.github/workflows/e2e-tier0-push-main.yaml` workflow is specifically designed to trigger only on changes to test code under `cypress/**`. Other separate workflows are responsible for running cypress tests when application code outside of `cypress/` changes. This separation of concerns is intentional.
Applied to files:
.github/workflows/pr-related-tests.yml.github/scripts/get-related-tests.js
📚 Learning: 2025-10-17T16:41:30.776Z
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2656
File: cypress/package.json:8-8
Timestamp: 2025-10-17T16:41:30.776Z
Learning: In the `cypress/package.json` file of the tackle2-ui repository, the npm scripts run with the current working directory set to `cypress/`, so relative paths in those scripts are resolved from the cypress folder, not the repository root.
Applied to files:
.github/workflows/pr-related-tests.yml.github/scripts/get-related-tests.js
🪛 GitHub Actions: CI (repo level)
.github/scripts/get-related-tests.js
[warning] 1-1: Code style issues found in the above file. Run Prettier with --write to fix.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
🔇 Additional comments (6)
.github/workflows/pr-related-tests.yml (1)
111-134: LGTM!The test summary job correctly handles all possible outcomes (success, failure, skipped) and provides clear status reporting in the GitHub step summary.
.github/scripts/get-related-tests.js (5)
20-28: LGTM!The mapping loader correctly handles file read and parse errors with appropriate error messages and exit codes.
30-48: LGTM!The git diff logic correctly handles both normal and fork PR scenarios. The fallback path now uses the same branch reference format as the primary path, avoiding the double-prefix issue that was previously identified and fixed.
114-140: LGTM!The glob expansion logic correctly uses
findto resolve patterns and gracefully falls back to the original pattern if expansion fails. The error handling is appropriate.
142-184: LGTM!The main function correctly orchestrates the script flow, handles edge cases (no changed files), and provides clear diagnostic output for debugging. The optional
--expandflag integration is clean.
1-184: Fix code formatting with Prettier.The pipeline reports code style issues in this file. Run Prettier to fix formatting before merging.
Run this command from the repository root:
npx prettier --write .github/scripts/get-related-tests.jsOr if you have a format script in package.json:
npm run format:write⛔ Skipped due to learnings
Learnt from: sjd78 Repo: konveyor/tackle2-ui PR: 2656 File: .prettierignore:9-18 Timestamp: 2025-10-17T17:03:52.480Z Learning: The tackle2-ui project uses a specific formatting setup: ESLint (with eslint-plugin-prettier) handles all JavaScript/TypeScript code files, while standalone Prettier handles non-code files. The .prettierignore file intentionally excludes **/*.js, **/*.ts, etc. to prevent duplicate formatting runs, as ESLint internally applies Prettier to code files.Learnt from: sjd78 Repo: konveyor/tackle2-ui PR: 2656 File: cypress/package.json:8-8 Timestamp: 2025-10-17T16:41:30.776Z Learning: In the `cypress/package.json` file of the tackle2-ui repository, the npm scripts run with the current working directory set to `cypress/`, so relative paths in those scripts are resolved from the cypress folder, not the repository root.
Signed-off-by: Shveta Sachdeva <[email protected]>
sshveta
force-pushed
the
pages_to_tests_mapping
branch
from
9181d5d to
91402f1
Compare
Signed-off-by: Shveta Sachdeva <[email protected]>
sshveta
force-pushed
the
pages_to_tests_mapping
branch
from
3da136a to
b616d21
Compare
Signed-off-by: Shveta Sachdeva <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
.github/scripts/get-related-tests.js (1)
1-28: Fix Prettier formatting issueThe pipeline reports a formatting check failure. Run the formatter to resolve:
npx prettier --write .github/scripts/get-related-tests.js
🧹 Nitpick comments (4)
cypress/test-mapping.json (1)
22-24: Note: Broader controls mapping will match all control subdirectory changesThe catch-all
client/src/app/pages/controlsmapping (lines 22-24) will match any file under the more specific control subdirectories (lines 7-21) because the script usesstartsWithmatching. For example, a change toclient/src/app/pages/controls/business-services/SomeFile.tsxwill trigger both:
cypress/e2e/tests/migration/controls/**/businessservices*.test.ts(specific)cypress/e2e/tests/migration/controls/**/*.test.ts(catch-all)This means all control tests will run for any control page change, which provides comprehensive coverage but may run more tests than necessary. If this is intentional for safety, consider adding a comment in the JSON explaining the overlap.
.github/scripts/get-related-tests.js (3)
87-92: Consider removing redundant test additionsLines 90-91 add
ci.test.tsandlogin.test.tswhen views change, but these are already indefaultTests(see test-mapping.json lines 72-73) which are always added at line 56. While theSetprevents duplicates (no functional bug), this code is redundant.If views need special handling beyond default tests, consider adding view-specific patterns; otherwise, this block can be removed.
95-112: Consider adding broader test coverage for significant unmapped changesLines 95-109 detect significant changes (in
client/src/,cypress/,package.json,tsconfig) that don't match specific page mappings, but only log a message without adding additional test patterns. This means only default tests run for these changes.For changes to infrastructure files (
package.json,tsconfig) or core Cypress code, running only default tests might miss important issues. Consider either:
- Adding all tests when infrastructure changes are detected
- Expanding the mapping to cover more paths in
client/src/beyond just pagesSince this is a draft PR, you might want to validate whether default tests provide sufficient coverage for these scenarios.
114-140: The--expandflag won't correctly handle globstar patterns withfindIf
--expandis used, thefindcommand at line 120 won't correctly expand patterns containing**(globstar syntax). Thefindcommand's-pathoption treats*as a single-level wildcard, not**as recursive.For example,
cypress/e2e/tests/migration/controls/**/*.test.tswould be passed as:find . -path "./cypress/e2e/tests/migration/controls/**/*.test.ts" -type fThis won't recursively match test files in subdirectories as intended.
Since the workflow doesn't appear to use the
--expandflag and Cypress natively supports glob patterns with--spec, this function may not be used in practice. However, if expansion is needed in the future, consider using a glob-aware tool or converting patterns to find-compatible syntax.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/scripts/get-related-tests.js(1 hunks).github/workflows/pr-related-tests.yml(1 hunks)cypress/test-mapping.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/pr-related-tests.yml
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2694
File: .github/workflows/e2e-tier0-push-main.yaml:7-8
Timestamp: 2025-11-13T23:21:33.345Z
Learning: In the tackle2-ui repository, the `.github/workflows/e2e-tier0-push-main.yaml` workflow is specifically designed to trigger only on changes to test code under `cypress/**`. Other separate workflows are responsible for running cypress tests when application code outside of `cypress/` changes. This separation of concerns is intentional.
📚 Learning: 2025-11-13T23:21:33.345Z
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2694
File: .github/workflows/e2e-tier0-push-main.yaml:7-8
Timestamp: 2025-11-13T23:21:33.345Z
Learning: In the tackle2-ui repository, the `.github/workflows/e2e-tier0-push-main.yaml` workflow is specifically designed to trigger only on changes to test code under `cypress/**`. Other separate workflows are responsible for running cypress tests when application code outside of `cypress/` changes. This separation of concerns is intentional.
Applied to files:
.github/scripts/get-related-tests.jscypress/test-mapping.json
📚 Learning: 2025-10-17T16:41:30.776Z
Learnt from: sjd78
Repo: konveyor/tackle2-ui PR: 2656
File: cypress/package.json:8-8
Timestamp: 2025-10-17T16:41:30.776Z
Learning: In the `cypress/package.json` file of the tackle2-ui repository, the npm scripts run with the current working directory set to `cypress/`, so relative paths in those scripts are resolved from the cypress folder, not the repository root.
Applied to files:
.github/scripts/get-related-tests.jscypress/test-mapping.json
🪛 GitHub Actions: CI (repo level)
.github/scripts/get-related-tests.js
[error] 1-1: Prettier formatting check failed in format:check step. File has formatting issues. Run 'prettier --write' to fix.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
🔇 Additional comments (3)
.github/scripts/get-related-tests.js (3)
30-48: LGTM!The git diff logic and fallback handling are correct. The fallback properly uses the
baseBranchparameter directly without adding an extraorigin/prefix, which resolves the previous concern.
50-75: LGTM!The matching logic correctly:
- Always includes default tests as a baseline
- Matches dev page changes against all applicable mapping entries (using
startsWithallows hierarchical matching)- Includes test files that were directly modified
142-184: LGTM!The main function provides clear orchestration:
- Proper argument validation
- Good logging for debugging
- Sensible fallback to default tests when no changes detected
- Conditional expansion based on flags
The overall flow is well-structured and easy to follow.
Signed-off-by: Shveta Sachdeva <[email protected]>
Signed-off-by: Shveta Sachdeva <[email protected]>
sshveta
force-pushed
the
pages_to_tests_mapping
branch
from
6717abf to
c0dff43
Compare
Signed-off-by: Shveta Sachdeva <[email protected]>
sshveta
force-pushed
the
pages_to_tests_mapping
branch
from
47a6089 to
4e93882
Compare
Signed-off-by: Shveta Sachdeva <[email protected]>
Signed-off-by: Shveta Sachdeva <[email protected]>
|
@sjd78 Do you suggest installing minikube and running tests ? |
1 participant
Summary
This PR it to set up an automated system to run only related Cypress tests when dev files change in PRs.
Maps dev page directories to their corresponding Cypress tests:
A workflow that:
How It Works:
Example:
If you change client/src/app/pages/applications/applications-table/ApplicationsTable.tsx, the system will run:
┌───────────────────────────────────────────────────────
│ PR RELATED TESTS WORKFLOW │
└────────────────────────────────────────────────────────
┌──────────────────────────────────────────────────────────────┐
│ JOB 1: detect-changes │
└──────────────────────────────────────────────────────────────┘
│
├── Step 1: Checkout Code
│
├── Step 2: Fetch Base Branch
│
├── Step 3: Run
get-related-tests.js│ │
│ ├── Compare PR branch files vs base
│ ├── Find related test specs
│ └── Output: TEST_PATTERNS=...
│
├── Step 4: Extract test patterns
│
├── Step 5: Determine:
│ ┌───────────────┬─────────────────────┐
│ │Patterns found?│ should_run_tests │
│ ├───────────────┼─────────────────────┤
│ │ YES │ true │
│ │ NO │ false │
│ └───────────────┴─────────────────────┘
│
└── Outputs:
• test_patterns
• should_run_tests
│
(decision step)
▼
┌──────────────────────────────────────────────┐
│ should_run_tests == true ? RUN TESTS │
└──────────────────────────────────────────────┘
│
YES ▼ NO ▼
┌───────────────────────────────────┐ ┌──────────────────────────┐
│ JOB 2: run-related-tests │ │ SKIPPED │
└───────────────────────────────────┘ └──────────────────────────┘
│
├── Checkout Code
├── Setup Node
├── Install Dependencies
├── Build UI
├── Start app on :3000
├── Run Cypress:
│ npx cypress run --spec "$TEST_PATTERNS"
│
└── Upload test results
│
▼
┌──────────────────────────────────────────────────────────────┐
│ JOB 3: test-summary │
└──────────────────────────────────────────────────────────────┘
│
├── Always runs
├── Writes PR summary:
│ • should_run_tests
│ • test_patterns
│ • test results status
│
└── Displays:
- "All tests passed" or
- "Some tests failed" or
- "No related tests to run"
Summary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.