Skip to content

Conversation

@limbonaut
Copy link
Collaborator

@limbonaut limbonaut commented Dec 10, 2025

I tested it on iOS in Sauce Labs, and it should work on Android too. This PR also fixes some issues specific to iOS in Sauce Labs runner: splitting CLI arguments correctly and using correct Appium parameter for iOS.

These changes are sufficient to get E2E tests green on iOS in the Godot SDK.

@limbonaut limbonaut changed the title feat: Implement CopyDeviceitem for Sauce Labs feat: Implement CopyDeviceitem for Sauce Labs & fix issues Dec 10, 2025
@limbonaut limbonaut changed the title feat: Implement CopyDeviceitem for Sauce Labs & fix issues feat: Implement CopyDeviceItem for Sauce Labs & fix issues Dec 10, 2025
@limbonaut limbonaut marked this pull request as ready for review December 10, 2025 11:00
- Add optional LogFilePath parameter to Invoke-DeviceApp and RunApplication
- Implement log file retrieval with fallback to system logs in SauceLabsProvider
- Add method overloads to AdbProvider and XboxProvider for compatibility
- Reduce code footprint by consolidating log retrieval logic
- Maintain backward compatibility with existing provider implementations

Co-authored-by: Claude Sonnet <claude@anthropic.com>
@limbonaut limbonaut changed the title feat: Implement CopyDeviceItem for Sauce Labs & fix issues Sauce: Implement CopyDeviceItem, log file parameter for RunApplication & fix issues Dec 10, 2025
limbonaut and others added 2 commits December 10, 2025 12:48
- Replace method overloads with single method using optional LogFilePath parameter
- Update base DeviceProvider class to include optional parameter
- Simplify all provider implementations (SauceLabs, Adb, Xbox)
- Remove conditional logic from Invoke-DeviceApp - single method call
- Clean up code by eliminating method overload complexity

Co-authored-by: Claude Sonnet <claude@anthropic.com>
- Add optional LogFilePath parameter to match other providers
- Ensures consistent method signature across all provider implementations
- Completes the refactoring to use optional parameters instead of overloads

Co-authored-by: Claude Sonnet <claude@anthropic.com>
@limbonaut
Copy link
Collaborator Author

@vaind
Copy link
Contributor

vaind commented Dec 12, 2025

On it! We are reviewing the PR and will provide feedback shortly.
Reference ID: 1

Comment on lines 374 to 382

# Split the arguments string by spaces, but handle quoted strings (both single and double quotes)
$argTokens = [regex]::Matches($Arguments, '(\"[^\"]*\"|''[^'']*''|\S+)') | ForEach-Object { $_.Value.Trim('"', "'") }

foreach ($token in $argTokens) {
$argumentsArray += $token
}

$launchBody['arguments'] = $argumentsArray

This comment was marked as outdated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even better, how about we change $arguments param to [object] and let users pass string or array?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, [string[]] actually accepts both a string and an array of strings

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have multiple places where we represent arguments as a single string. I suppose I can refactor all of that in this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you shouldn't really need to change that. a single string works the same as an array of a a single string

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, we'd want to use arrays to eliminate the guesswork. But it clashes with command format string substitutions in device providers. I've converted most of our pathways to use an array of arguments, but I'm still a bit conflicted about it.

Copy link
Contributor

@vaind vaind Dec 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you're only changing this for the invoke-app flow - I'd just join the string by a space by default, no escaping, quoting, etc.
If someone needs custom escaping or quoting, they can always pass a single string.
let's keep it simple

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect this to work:

Invoke-App -Exe "Game.exe" -Arguments @("start-level", "Big Mountain")

But I get your point, and we can remove the safety. If we don't want to add such guarantees, we should clearly communicate such expectations. I'll add it to the docs then.

Copy link
Contributor

@vaind vaind Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean if you want, you can do some simple quoting but I probably wouldn't bother. It's not all that usual to have spaces in args for what we do here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can leave it as is. Is there anything else we should address before it can be merged?

Copy link
Contributor

@vaind vaind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've found a couple of bugs and a few improvement ideas

Updated device provider APIs to consistently accept arguments as string arrays rather than pre-formatted strings, improving type safety and eliminating argument parsing ambiguities. Added ConvertArgumentsToString method to DeviceProvider base class for consistent string conversion when needed by underlying tools.

Co-authored-by: Claude <claude@anthropic.com>
@limbonaut
Copy link
Collaborator Author

limbonaut commented Dec 16, 2025

I think I broke arguments on iOS. I'll check.
Never mind.

@vaind vaind self-requested a review December 19, 2025 12:10
Copy link
Contributor

@vaind vaind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late re-review. This looks pretty good to me but needs some tests for the new code (ideally against real SauceLabs, but unit tests would do too)

Comment on lines +255 to +259
[hashtable] RunApplication([string]$AppPath, [string[]]$Arguments, [string]$LogFilePath = $null) {
if (-not ([string]::IsNullOrEmpty($LogFilePath))) {
Write-Warning "LogFilePath parameter is not supported on this platform."
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this codeblock mixes tab & space separators, breaking the indent (2 vs 4) for some. Please use spaces instead to keep the indentation consistent across the repo.


# Skip the key and value we just validated
$i += 2
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider warning or a debug log in the "else" branch. Although, I guess since this is just a nice-to-nave anyway, maybe it's ok as is.

Array of arguments to pass to the executable when starting it.
The caller is responsible for quoting/escaping the arguments.
For example, if the executable requires arguments with spaces, they should be quoted:
Invoke-DeviceApp -ExecutablePath "Game.exe" -Arguments @('"/path/to/some file.txt"', '--debug')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfectly explained, thanks! 👍

Comment on lines +51 to +59
# Check iOS Fixture (not supported yet)
# $iosFixture = Join-Path $PSScriptRoot 'Fixtures' 'iOS' 'TestApp.ipa'
# if (Test-Path $iosFixture) {
# $TestTargets += Get-TestTarget `
# -Platform 'iOSSauceLabs' `
# -Target 'iPhone 13 Pro' `
# -FixturePath $iosFixture `
# -ExePath 'com.saucelabs.mydemoapp.ios' `
# -Arguments '--test-arg value'
# -Arguments @('--test-arg', 'value')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIU this PR enables iOS support. Are you going to enable iOS tests in a followup PR? As currently the new code paths don't seem to be tested (CopyDeviceItems, LogFilePath and CheckAppFileSharingCapability)

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.

3 participants