react-native-code-push

The E2E test runner (e2e/run.ts) executes a series of automated phases to validate CodePush functionality across different scenarios. The process is divided into several distinct phases:

1. Phase 1 — Basic Flow (flows/): Validates standard app launch, restart stability, and successful update installation (detecting UPDATED! and specific metadata).
2. Phase 2 — Rollback to Binary (flows-rollback/): Tests the ability to automatically roll back to the original binary version when a release is disabled via npx code-push update-history -e false.
3. Phase 3 — Partial Rollback (flows-partial-rollback/): Verifies rolling back from one update (e.g., v1.0.2) to a previous update (e.g., v1.0.1) rather than the binary.
4. Phase 4 — Optional Install Mode (flows-optional/): Validates non-mandatory updates based on app lifecycle events (relaunch, restart button, background/foreground transitions) and the --minimum-background-duration setting.
5. Phase 5 — Binary Patch Updates (flows-binary-patch/): Tests the application of patches directly onto the app binary. It validates successful patch installation and fallback mechanisms (to full archives) when patches are corrupted, mismatched, or invalid.
6. Phase 6 — Asset Diff Updates (flows-asset-diff/): Tests efficient asset updates by downloading only the differences (diffPackages). It validates the merging of assets and fallback logic when diffs fail due to corruption or manifest mismatches.

The release history is a JSON object where each key is an app version. This structure allows the client to determine which OTA (Over-The-Air) update to download based on the current binary version.

Key fields within a version object include:

• enabled: Boolean indicating if the update is active.
• mandatory: Boolean indicating if the update must be installed before the app can be used.
• downloadUrl: The URL to the bundle.
• packageHash: The hash of the package.
• rollout: Percentage of users to receive the update.
• binaryPatchDownloadUrl: Present only if the release was published using --binary-bundle-path.
• diffPackages: An object containing asset diff archives. Each entry maps a packageHash (the version the archive was diffed against) to its download URL.

{
  "1.0.0": {
    "enabled": true,
    "mandatory": false,
    "downloadUrl": "",
    "packageHash": ""
  },
  "1.0.1": {
    "enabled": true,
    "mandatory": false,
    "downloadUrl": "https://storage.example.com/bundles/ios/staging/a1b2c3...",
    "packageHash": "a1b2c3...",
    "rollout": 100,
    "minimumBackgroundDuration": 600
  }
}

Using --platform both executes iOS and Android scenarios side-by-side from a single checkout.

Requirements & Behavior:

• Requires both a booted iOS Simulator and a running Android emulator/device to be active at the same time.
• Isolation: Each platform maintains its own app entry (App.ios.tsx / App.android.tsx), mock server port (18081 / 18082), artifact records, and CLI output roots under the app's build/ directory. Nothing is serialized between pipelines.
• Shared Resources: Native builds share the app directory and node_modules. The watchman reset and library sync are performed once at the start.
• Output: Both pipelines write to a single terminal. Output is prefixed with platform identifiers (e.g., via runner phase banners or mock server lines).
• Failure Handling: A failure on one platform does not stop the other. The command exits with a non-zero status if either platform fails.
• Performance Note: Running both platforms shares the machine's CPU between two simulators, two bundlers, and two Maestro drivers. If tests flake due to load, use --exclude-timing-sensitive and --retry-count to stabilize.

When performing a diff update, CodePush may attempt to use a patch archive before falling back to a full archive. onUpdateArchiveResult provides details on this process.

Archive Types:

• asset-diff: Differences relative to the previous OTA update.
• binary-patch: Differences relative to the bundle embedded in the app binary.
• full: The entire update.

UpdateArchiveResult Fields:

• status: Either "applied" (patch worked) or "fallback" (patch failed, full archive used).
• archive: The UpdateArchive used or the last attempted patch archive.
• fallbackReason: The ArchiveFallbackReason explaining why a full archive was needed (only if status is "fallback").
• totalDurationMs: Time from the first patch download start to the end of the last patch attempt (excludes full archive download time).
• attempts: An array of UpdateArchiveAttempt[] containing all attempted patch archives in order.

The E2E test runner (e2e/run.ts) executes a series of automated testing phases to verify CodePush functionality across different scenarios. Understanding these phases helps in interpreting test results and knowing which flows are being covered:

1. Basic Flows (flows/): Verifies app launch, restart stability, and standard update installation (syncing to a specific version).
2. Rollback to Binary (flows-rollback/): Verifies that if a release is disabled via npx code-push update-history -e false, the app automatically rolls back to the version bundled in the binary.
3. Partial Rollback (flows-partial-rollback/): Verifies that if an update is disabled, the app rolls back to the previous successful update rather than the binary.
4. Optional Install Modes (flows-optional/): Tests how non-mandatory updates (-m false) behave under different lifecycle events (relaunch, restart button, background/foreground transitions) and how --minimum-background-duration affects application timing.
5. Binary Patch Updates (flows-binary-patch/): Tests the efficiency and reliability of binary patches. It verifies successful patch application, handling of image assets, and fallback mechanisms when patches are stale, corrupt, or built for the wrong platform.
6. Asset Diff Updates (flows-asset-diff/): Tests the advanced asset-diffing mechanism. It verifies that the client can download only changed assets (diff archives) and correctly merges them, while also testing fallbacks to patch or full archives if the diff is corrupted or the manifest is invalid.

Using the --platform both flag executes iOS and Android scenarios in parallel from a single checkout. This can nearly halve the wall-clock time but increases CPU load on the host machine.

Key Characteristics

• Parallelism: Each platform runs its own device, app entry points (App.ios.tsx, App.android.tsx), mock server ports (18081, 18082), and artifact recordings. There is no serialization between the two pipelines except for the shared native build (which shares the app directory and node_modules), Watchman initialization, and library synchronization.
• Output: Logs from both platforms are interleaved in the same terminal. While runner banners and mock server logs are prefixed with the platform name, raw outputs from gradle, xcodebuild, and maestro will be mixed.
• Error Handling: If one platform fails, the other continues to run. The command will exit with a non-zero code if either platform fails.
• Resource Management: Because running two simulators, two bundlers, and two Maestro drivers simultaneously is resource-intensive, timing-sensitive scenarios might become unstable. If you encounter timing issues, use --exclude-timing-sensitive or --retry-count to stabilize the run.

npm run e2e -- --app RN0840 --platform both