feat: tauri service #6
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
goosewobbler
force-pushed
the
feat/extract-native-utils
branch
from
8bf7bfe to
3d60d8d
Compare
goosewobbler
force-pushed
the
feat/extract-native-utils
branch
from
7ecdcb1 to
de786e9
Compare
The DISPLAY environment variable was not available in the WDIO worker process, causing ChromeDriver and diagnostic commands to fail when trying to launch the Tauri binary with GTK. This fix: 1. Sets DISPLAY in the worker process environment (onWorkerStart) so that ChromeDriver and all child processes have access to the X server 2. Configures WDIO to connect to tauri-driver's WebDriver endpoint instead of spawning a separate ChromeDriver instance 3. Keeps DISPLAY set when spawning tauri-driver for redundancy 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
goosewobbler
force-pushed
the
feat/extract-native-utils
branch
from
de786e9 to
bc98dd1
Compare
Following the official Tauri WebDriverIO example, this commit fixes the integration by: 1. NOT converting browserName from 'tauri' to 'chrome' - this was causing WDIO to spawn ChromeDriver instead of connecting to tauri-driver 2. Setting hostname to '127.0.0.1' (not 'localhost') to match Tauri docs 3. Removing all Chrome-specific options (goog:chromeOptions, args, etc) since tauri-driver handles this internally 4. Keeping browserName as 'tauri' and only resolving the binary path in tauri:options.application This allows WDIO to properly connect to tauri-driver which then manages the WebKit WebDriver session. References: - https://v2.tauri.app/develop/tests/webdriver/example/webdriverio/ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This optimization significantly improves CI performance by building Tauri applications once per OS and reusing the binaries across all test types. Changes: 1. Created _ci-build-tauri-apps.reusable.yml workflow - Builds Tauri apps for a specific OS - Uploads binaries as artifacts (per OS, unlike packages) - Follows the same pattern as _ci-build.reusable.yml 2. Updated ci.yml to add build-tauri-apps jobs - build-tauri-apps-linux: Builds Tauri apps on Linux - build-tauri-apps-windows: Builds Tauri apps on Windows - Both run in parallel with other jobs after package build - e2e-tauri-matrix now depends on these jobs 3. Updated _ci-e2e-tauri.reusable.yml to download pre-built binaries - Removed Tauri app build step (was rebuilding for each test type) - Added download step for Tauri app binaries - Added tauri_cache_key input parameter Benefits: - Much faster: Build once (~2-5 min) vs rebuild 4x per OS - Consistent: All test types on same OS use identical binaries - Parallel: Build jobs run alongside other jobs - Cheaper: Less compute time = lower GitHub Actions costs Example: On Linux with 4 test types (standard, window, multiremote, standalone), this saves ~6-15 minutes of build time per run. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
The multiremote tests were failing because WDIO was trying to spawn a driver for browserName='tauri', which doesn't exist. Following the official Tauri WebDriverIO example, we should NOT set browserName at all when using tauri-driver. Changes: 1. Delete browserName from capabilities after validation - This prevents WDIO from trying to spawn a driver - When hostname/port are set, WDIO connects directly to tauri-driver 2. Simplify onWorkerStart to use already-resolved binary path - The binary path is resolved in onPrepare and stored in capabilities - No need to call getTauriBinaryPath again in onWorkerStart - Just verify the file exists 3. Add existsSync import for binary verification This fixes the multiremote error: "Unknown browser name 'tauri'. Make sure to pick from one of the following chrome,googlechrome,chromium..." 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Following the official Tauri WebDriverIO example more closely, browserName should NOT be set in capabilities at all. WDIO uses browserName to determine which driver to spawn, but we're connecting directly to tauri-driver via hostname/port. Changes: 1. Updated wdio.tauri.conf.ts - Removed browserName from all capabilities (standard and multiremote) - Made browserName optional in local TauriCapability type 2. Updated packages/tauri-service/src/types.ts - Made browserName optional in TauriCapabilities interface - Allows configs to omit browserName entirely 3. Updated packages/tauri-service/src/launcher.ts - Changed validation to accept missing browserName - Only validate if browserName is present (must be 'tauri') - Only delete browserName if it exists This matches the official Tauri example which doesn't set browserName: https://v2.tauri.app/develop/tests/webdriver/example/webdriverio/ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Fixed two critical issues with the Tauri app build workflow:
1. Linux: Missing XCB library dependencies
- Added all required X11/XCB development packages
- Specifically: libxcb-shape0-dev, libxcb-xfixes0-dev, and related libs
- These are needed for linking Tauri binaries on Linux
- Error was: "unable to find library -lxcb-shape"
2. Windows: PowerShell Compress-Archive timestamp issue
- Rust target directories can have files with timestamps outside
the valid ZIP file range (1980-2107)
- PowerShell's Compress-Archive fails with: "The DateTimeOffset
specified cannot be converted into a Zip file timestamp"
- Solution: Normalize file timestamps before compression
- Files with invalid timestamps are set to 2020-01-01
Changes:
- Updated _ci-build-tauri-apps.reusable.yml to install all X11/XCB deps
- Updated upload-archive action to normalize timestamps on Windows
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Standalone tests use WDIO's remote() function which reads connection settings from capabilities directly, not from the config object. Error: "No browserName defined in capabilities nor hostname or port found!" Solution: Set hostname and port in capabilities as well as config: - cap.hostname = '127.0.0.1' - cap.port = 4444 (or configured tauriDriverPort) This ensures both normal and standalone modes can connect to tauri-driver. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
The previous approach of setting hostname/port in the service's onPrepare
hook didn't work because WDIO reads the config before the hook runs.
Following the official Tauri WebDriverIO example, hostname and port must
be set directly in the wdio config object:
```javascript
export const config = {
hostname: '127.0.0.1',
port: 4444,
// ... other config
}
```
This ensures WDIO connects to tauri-driver for all test modes (standard,
multiremote, and standalone).
Changes:
1. Added hostname and port to wdio.tauri.conf.ts export
2. Simplified launcher to only log connection info, not set it
3. Removed redundant capability setting (config is sufficient)
References:
- https://v2.tauri.app/develop/tests/webdriver/example/webdriverio/
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixed two issues with Tauri testing:
1. Multiremote capabilities handling
- onWorkerStart can receive capabilities as an array for multiremote
- Changed signature to accept TauriCapabilities | TauriCapabilities[]
- Made diagnostics gracefully skip if capabilities structure is unexpected
- Added better error logging to debug capability structure issues
2. GTK display errors on Linux
- REMOVED setting DISPLAY in onWorkerStart
- Setting DISPLAY prevents WDIO's xvfb service from wrapping the worker
- Logs showed: "shouldRun=false" because DISPLAY was already set
- Now xvfb-run properly wraps the worker and sets DISPLAY
- tauri-driver inherits DISPLAY from xvfb-wrapped process environment
Flow:
1. WDIO autoXvfb wraps worker with: xvfb-run
2. xvfb-run sets DISPLAY=:99 in worker environment
3. onPrepare spawns tauri-driver with {...process.env}
4. tauri-driver inherits DISPLAY and passes it to Tauri app
5. Tauri app successfully connects to X server
Error fixed: "Gtk-WARNING: cannot open display: :99"
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The pre-built Tauri binaries weren't being found on Windows because they were extracted to the wrong location. Problem: - Archive contains: fixtures/tauri-apps/*/src-tauri/target/** - Was extracting to: tauri-apps-Windows/ - Tests looked for: fixtures/tauri-apps/*/src-tauri/target/** - Result: "No Tauri target directory found" → tries to build → fails Solution: - Extract to repository root (path: .) - Files now end up in correct location: fixtures/tauri-apps/*/src-tauri/target/ - Added verification step to check binaries are in the right place This matches how package builds are extracted (they also extract to repo root). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
goosewobbler
force-pushed
the
feat/extract-native-utils
branch
from
19e71d4 to
9b75521
Compare
goosewobbler
force-pushed
the
feat/extract-native-utils
branch
from
56f1f38 to
6cb3ba3
Compare
goosewobbler
force-pushed
the
feat/extract-native-utils
branch
from
6cb3ba3 to
a0ef24f
Compare
goosewobbler
force-pushed
the
feat/extract-native-utils
branch
2 times, most recently
from
873d9dd to
3102a10
Compare
goosewobbler
force-pushed
the
feat/extract-native-utils
branch
from
3102a10 to
b6f8711
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.