[build-tools] Add eas/report_maestro_test_results build function

[hSATAC]

Why

Maestro test jobs produce per-flow results on the build worker (pass/fail, duration, error messages, retries), but this data is lost after the job finishes.

We want to persist these as WorkflowDeviceTestCaseResult records to surface test outcomes in the dashboard.

How

Add a new eas/report_maestro_test_results build function that:

1. Parses JUnit XML reports from the junit_report_directory (primary data source)
2. Enriches with flow file paths from Maestro's ai-*.json debug output in tests_directory
3. Calls the createWorkflowDeviceTestCaseResults GraphQL mutation via gql.tada + graphqlClient

Key details:

• JUnit XML as primary data source — ai-*.json only used for flow_file_path mapping and retry count
• junit_report_directory added as output on eas/__maestro_test (set when output_format=junit) and as optional input on eas/report_maestro_test_results
• Retry detection by counting occurrences of the same flow across timestamp directories (works for both reuse_devices: true and false patterns)
• Duplicate testcase name detection — skips report when Maestro config-level name collisions make flow-to-file mapping ambiguous
• Path relativization uses fs.realpath to handle symlinks (/tmp → /private/tmp on macOS)
• Best-effort reporting — errors are logged but never fail the build step
• graphqlClient exposed on CustomBuildContext for step functions to use
• 39 unit tests covering JUnit parsing, flow metadata, retry detection, properties/tags, duplicate detection, and error resilience

Test Plan

• Automation tests
• Manual test locally with https://github.com/expo/universe/pull/24814

[linear]

ENG-19032 Report WorkflowTestCaseResult in reuse_device: true route

[github-actions]

Size Change: +3.48 kB (0%)

Total Size: 72.7 MB

Filename	Size	Change
./packages/eas-cli/dist/eas-linux-x64.tar.gz	72.7 MB	+3.48 kB (0%)

_{compressed-size-action}

[codecov]

Codecov Report

❌ Patch coverage is 92.98246% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 52.76%. Comparing base (1604b7b) to head (1476a49).

Files with missing lines	Patch %	Lines
...d-tools/src/steps/functions/maestroResultParser.ts	91.41%	11 Missing ⚠️
...ls/src/steps/functions/reportMaestroTestResults.ts	97.44%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3388      +/-   ##
==========================================
+ Coverage   52.26%   52.76%   +0.50%     
==========================================
  Files         804      806       +2     
  Lines       33450    33621     +171     
  Branches     6975     7014      +39     
==========================================
+ Hits        17480    17737     +257     
+ Misses      15885    15799      -86     
  Partials       85       85              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Subscribed to pull request

File Patterns	Mentions
**/*	@douglowder

Generated by CodeMention

[hSATAC]

The Size / compare check is failing now due the the yarn gql prebuild script. The graphql was not deployed yet so it can't fetch the required new gql schema.

[sjchmiela]

nnnnnooooooo, really??

[hSATAC]

Yeah, the JUnit is super simple like this:

<?xml version='1.0' encoding='UTF-8'?>
<testsuites>
  <testsuite name="Test Suite" device="iPhone 16 - iOS 18.6 - 59572B21-FEAF-4BEC-B8EB-5793C9A31034" tests="6" failures="3" time="78.0">
    <testcase id="settings_screen" name="settings_screen" classname="settings_screen" time="22.0" status="ERROR">
      <properties>
        <property name="priority" value="high"/>
        <property name="suite" value="smoke"/>
        <property name="jira" value="APP-101"/>
      </properties>
      <failure>Element not found: Text matching regex: Settings</failure>
    </testcase>
  </testsuite>
</testsuites>

[sjchmiela]

After having parsed both commands and JUnit, what is your professional opinion on which one should we use?

[hSATAC]

After looking at both, I’m leaning toward using the original JSON as the source of truth.

It simply has more complete data, and we can support all formats without forcing users to adopt JUnit.

With JUnit, we’d still need JSON anyway (no tags / flowFileName), and duration is only second-level precision.

The only real advantage of JUnit is stability — it’s less likely to change upstream. JSON doesn’t give us that guarantee, so if we go with it, we might want some automation to detect schema changes early.

[github-actions]

⏩ The changelog entry check has been skipped since the "no changelog" label is present.