feat(providers): add Digital.ai Testing cloud provider#120
Merged
Winify merged 1 commit intoJun 16, 2026
Conversation
|
|
Winify
reviewed
Jun 16, 2026
Collaborator
|
@Arundoss-digitalai I have reviewed the PR, minor notes only Decide if you want to resolve, then I can merge and publish a version 🚀 |
Adds Digital.ai (formerly Experitest/SeeTest) at parity with the other cloud providers, covering both web (Selenium) and mobile (Appium) plus app management. Connects to <DIGITALAI_CLOUD_URL>/wd/hub over https:443; authentication rides in the accessKey capability. Web (Selenium) sessions use flat digitalai:* capabilities — digitalai:accessKey, digitalai:testName, and digitalai:osName (combined from os/osVersion). The flat form is what activates the reporter: the cloud returns digitalai:reportUrl, which is surfaced in the start_session output. Browser names map edge -> MicrosoftEdge. Mobile (Appium) sessions use the nested digitalai:options object — accessKey, testName, and a deviceQuery for dynamic device selection (explicit, or built from deviceName/platformVersion). The Appium server/version is selected at the Digital.ai project level (configure the project for Appium-server execution), not pinned here. Native apps are referenced as cloud:<package-or-bundle>. Pass/fail is reported via onSessionClose using the seetest:client.setReportStatus automation command, for both web and mobile. list_apps/upload_app are wired through the Applications REST API (GET /api/v1/applications, POST /api/v1/applications/new) using Bearer auth with the access key, leaving the other providers' auth and behaviour unchanged. Generated reproduction code (wdio://session/current/code) emits the Digital.ai hub connection and scrubs the access key to a process.env reference (flat and nested forms) so secrets are never baked into generated output. New start_session param: deviceQuery. Credentials: DIGITALAI_CLOUD_URL / DIGITALAI_ACCESS_KEY. Verified live against a Digital.ai cloud: web and mobile sessions (both generating reports with pass/fail status) plus list_apps. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
cc82ba3 to
76e4542
Compare
Winify
approved these changes
Jun 16, 2026
Contributor
Author
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Proposed changes
Adds Digital.ai Testing (formerly Experitest/SeeTest) as a cloud provider, at parity with the existing BrowserStack / Sauce Labs / TestMu / TestingBot integrations — covering web (Selenium) and mobile (Appium) sessions plus app management.
Sessions connect to
<DIGITALAI_CLOUD_URL>/wd/huboverhttps:443; authentication rides in the access-key capability (no WebDriver basic auth).Web (Selenium) — flat
digitalai:*capabilities:digitalai:accessKey,digitalai:testName, anddigitalai:osName(combined fromos/osVersion).digitalai:reportUrl, which is surfaced in thestart_sessionoutput.edge→MicrosoftEdge.Mobile (Appium) — nested
digitalai:optionsobject:accessKey,testName, and adeviceQueryfor dynamic device selection (explicit, or built fromdeviceName/platformVersion).cloud:<package-or-bundle>.Pass/fail reporting — marked via
onSessionCloseusing theseetest:client.setReportStatusautomation command, for both web and mobile (consistent with how the other providers mark status).App management —
list_apps/upload_appwired through the Applications REST API (GET /api/v1/applications,POST /api/v1/applications/new) using Bearer auth with the access key. The shared cloud-provider tool gains a Bearer path; the other providers' auth and behaviour are unchanged.Generated reproduction code (
wdio://session/current/code) emits the Digital.ai hub connection and scrubs the access key to aprocess.envreference (flat and nested forms) so secrets are never baked into generated output.New
start_sessionparam:deviceQuery.Credentials:
DIGITALAI_CLOUD_URL/DIGITALAI_ACCESS_KEY.Verified live against a Digital.ai cloud: web and mobile sessions (both generating reports with pass/fail status) plus
list_apps.Types of changes
Checklist
Further comments
Scope / design notes
src/providers/cloud/digitalai.provider.ts) registered viaproviders/registry.ts; existing providers are untouched. The only shared-code change is an additive Bearer-auth path incloud-provider.tool.ts(existing Basic-auth providers produce byte-identical requests).digitalai:*capabilities (required to activate the Selenium reporter), mobile uses the nesteddigitalai:optionsobject (Appium 2 convention), and the REST API usesBearer.Report status & BiDi (opt-in)
capabilities: { 'wdio:enforceWebDriverClassic': true }. This is documented in the README and left to the user rather than forced (BiDi-dependent features otherwise stay available).Testing
list_apps/upload_app, and generated code (incl. secret scrubbing); full suite green, lint clean.list_apps.Reviewers: @webdriverio/project-committers