ci: [SDK-4687] add Unity SDK E2E workflow#870
Merged
Conversation
- create-demo-env: route inputs through step env to avoid the documented
Actions script-injection pattern. Same behavior; values arrive as
environment variables instead of being textually substituted into the
shell program.
- e2e.yml: rebase the iOS DerivedData cache key on inputs that exist at
checkout time (manifest.json, ProjectVersion.txt, ProjectSettings.asset,
com.onesignal.unity.{ios,core}/Editor/**, ExportOptions.plist) instead
of the Unity-exported pbxproj/Podfile, which don't exist when the cache
step runs and caused the key to collapse to a single global slot.
Co-authored-by: Cursor <cursoragent@cursor.com>
Matches the Capacitor demo .env pattern (channel `7ec2ece9-...`). Required for the Appium "send WITH SOUND notification" spec on Android, which posts a notification using this channel ID; without it the channel falls back to default and the sound assertion fails. Exposed as an action input so a future caller can override. Co-authored-by: Cursor <cursoragent@cursor.com>
sherwinski
reviewed
May 18, 2026
Comment on lines
+138
to
+145
| - name: Pod install | ||
| working-directory: examples/demo/Build/iOS | ||
| run: | | ||
| if [ -f Podfile ]; then | ||
| pod install --repo-update | ||
| else | ||
| echo "No Podfile in Unity-exported Xcode project; skipping pod install" | ||
| fi |
Contributor
There was a problem hiding this comment.
When wouldn't there be podfile present in this case? Should this fail instead?
fadi-george
added a commit
that referenced
this pull request
May 18, 2026
EDM4U + com.onesignal.unity.ios/Editor/OneSignaliOSDependencies.xml always generate a Podfile during iOS export because OneSignalXCFramework is consumed via CocoaPods. The previous fallback that silently skipped pod install on a missing Podfile would mask EDM4U / post-processor failures and ship an IPA without OneSignal native deps. Surface it as an ::error:: instead. Addresses Sherwin's review comment on #870. Co-authored-by: Cursor <cursoragent@cursor.com>
Drop the Podfile presence check; `pod install` already errors out with "[!] No \`Podfile' found in the project directory." when it's missing, which is enough to fail the step and surface a broken EDM4U / post-processor run. Addresses Sherwin's review comment on #870. Co-authored-by: Cursor <cursoragent@cursor.com>
81a5f76 to
ab21e05
Compare
sherwinski
approved these changes
May 18, 2026
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.
Description
One Line Summary
Add a GitHub Actions e2e workflow that builds the Unity demo app on each
rel/**push (or manual dispatch) and runs the shared Appium suite against BrowserStack viaOneSignal/sdk-shared.Details
Motivation
Capacitor, DotNet, and Flutter SDKs already produce demo APK/IPAs in CI and exercise them against the shared Appium reusable workflow (Capacitor, DotNet). Unity already supports the E2E hooks (E2E_MODE, AccessibilityBridge, appium-unity-android/ios external IDs), but the workflow itself and a real-device iOS build entrypoint were missing. This PR closes that gap.
Scope
.github/workflows/e2e.yml: new workflow withbuild-android(ubuntu, game-ci/unity-builder, Maven-wait for the native Android SDK) andbuild-ios(macos, game-ci/unity-builder + xcodebuild archive/export usingexamples/demo/iOS/ExportOptions.plist), thene2e-android/e2e-iosjobs that reuseOneSignal/sdk-shared/.github/workflows/appium-e2e.yml@mainwithsdk-type: unity.examples/demo/Assets/Scripts/Editor/BuildScript.cs: addBuildiOSDevice()so CI can produce a device IPA. The existingBuildiOSSimulator()emits a simulator binary that BrowserStack cannot install..github/actions/create-demo-env/action.yml: small composite action that writes the demo.env(ONESIGNAL_APP_ID,ONESIGNAL_API_KEY,E2E_MODE=true), matching the Flutter pattern.Trigger surface matches other SDKs:
push: rel/**and manualworkflow_dispatchwith aplatformchoice (android/ios/both).Activation
Uses Unity Pro serial activation via game-ci, sourcing
UNITY_SERIAL+UNITY_USERNAME+UNITY_PASSWORDrepo secrets (named seat assigned toteam-sdk-platform@onesignal.com).Testing
Manual testing
sdk-shared/appium/scripts/run-local.sh --sdk=unity --platform=android|ios, which uses the sameBuildScript.BuildAndroidEmulatorentrypoint as CI.e2e.ymlwithplatform=androidfrom this branch, confirm Unity activation succeeds anddemo-apkartifact uploads, then dispatch withplatform=bothto validate iOS signing/IPA export and the full BrowserStack run.Unit testing
Not applicable. CI workflow / build script entrypoint only; no runtime SDK behavior change.
Affected code checklist
Checklist
Overview
Testing
UNITY_SERIALsecret is set)Final pass
Made with Cursor