Skip to content

Fix iOS and web CI workflow failures#139

Merged
handstandsam merged 9 commits into
mainfrom
fix-ios-web-checks
May 23, 2026
Merged

Fix iOS and web CI workflow failures#139
handstandsam merged 9 commits into
mainfrom
fix-ios-web-checks

Conversation

@handstandsam
Copy link
Copy Markdown
Collaborator

Summary

  • Wikipedia-trails (web): Ubuntu 24.04 renamed libasound2 to libasound2t64. The old package name has no installation candidate on Noble, causing the apt-get install step to exit 100 and skip the trail entirely.
  • iOS-contacts-trails: The job was consistently hitting the 45-minute timeout-minutes ceiling (last run took ~46 min including simulator boot, trail execution, report generation, and artifact upload). Increased timeout to 60 minutes.

Test plan

  • Wikipedia-trails job completes the Playwright dependency install without error
  • iOS-contacts-trails job no longer gets cancelled by the job timeout

Wikipedia-trails: Ubuntu 24.04 renamed libasound2 → libasound2t64; the old
package name has no installation candidate and caused the apt-get step to fail.

iOS-contacts-trails: job was hitting the 45-minute timeout (run took ~46 min);
increase timeout to 60 minutes to give the job room to complete and upload artifacts.
Wikipedia-trails: Gradle build for :trailblaze-desktop:jar alone takes ~30min
on the ubuntu-latest runner, hitting the old 30-minute ceiling before the trail
can execute. 60 minutes gives enough headroom for build + daemon startup + trail.

iOS-contacts-trails: add test-search-no-results as the second trail run after
the existing test-search-by-first-name, reusing the already-running daemon.
Without this, the daemon starts without the example packs loaded:
- Wikipedia: the 'wikipedia' target can't be resolved, causing the trail to
  hang until the 1800s internal timeout fires
- iOS Contacts: contacts_ios_searchContacts (used by test-search-no-results)
  is not registered because the contacts pack isn't loaded
iOS: TRAILBLAZE_CONFIG_DIR must be exported before the first ./gradlew call.
JavaExec subprocesses in CI inherit the Gradle daemon's environment (set at
daemon start), not the caller's shell. The inline VAR=value ./trailblaze pattern
never reached the JVM because the daemon was already running from the pre-build
:trailblaze-desktop:jar step without the variable.

Web: Same config-dir fix, plus pre-install Playwright Chromium via
bunx playwright@1.59.0 install chromium before starting the daemon. The JVM
and npm Playwright libraries share ~/.cache/ms-playwright, so pre-installing
avoids the download happening inside DaemonClient's hardcoded 1800s poll window.
…ailblaze.yaml

When TRAILBLAZE_CONFIG_DIR is set to an example workspace (e.g.
examples/ios-contacts/trails/config), the resolver was using the
workspace-root configFile (trails/config/trailblaze.yaml) to resolve
pack targets. This caused the repo-root contacts pack (Android tools
only) to be loaded instead of the ios-contacts pack (iOS scripted tools
including contacts_ios_searchContacts).

The fix: when the configDir contains its own trailblaze.yaml, prefer it
as the configFile. This makes the daemon load targets from the example
workspace's pack definitions rather than the outer workspace root.

Also increase DaemonClient.RUN_POLL_TIMEOUT_MS from 30 to 60 minutes
so the Wikipedia trail (which takes ~30 min to execute) has enough
headroom without hitting the client-side poll timeout.
The synthesized wrapper in DaemonScriptedToolBundler created a __client
shim with only callTool, leaving __client.tools undefined. Any scripted
tool using the client.tools.<name>(args) authoring surface then crashed
at runtime with "cannot read property 'X' of undefined".

Adds a Proxy on __client.tools that maps property accesses to
__client.callTool dispatches, mirroring the SDK's createToolsProxy
implementation. Pinned by a new synthesizeWrapper unit test.
…s and simplify assertion

contacts_ios_searchContacts already types the query, so the extra
tapOnElementBySelector + inputText steps were doubling the input.
The assertVisibleBySelector used a version-specific iOS text
("No Results for ZzZzNoSuchContact") that only appears on iOS 26;
iOS 18 (CI runner) shows only "No Results". Simplify to just
"No Results" which matches across iOS versions.
…rail

iOS 18 (CI runner) shows an empty contacts list with no visible
"No Results" text when searching returns no matches; the assertion
cannot be made reliably across iOS versions. The meaningful coverage
here is that contacts_ios_searchContacts returns without error when
openFirstResult:false — that behavior is still exercised.
Use assertVisibleWithAccessibilityText to verify the iOS 18 'No Results'
accessibility text appears after searching for a non-existent contact.
This matches what the contacts_ios_searchContacts tool itself uses
internally to detect the no-results state.
@handstandsam handstandsam merged commit 30a7281 into main May 23, 2026
9 of 10 checks passed
@handstandsam handstandsam deleted the fix-ios-web-checks branch May 23, 2026 20:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant