chore(ci): drop the nightly E2E iOS and Android runs, rebuild only on request

[kherembourg]

E2E iOS and E2E Android each fired a cron every single day over Sep 1–16 2026 — 15 runs, 15 days, no gap — whether or not anything had changed. Measured macOS minutes for E2E iOS over the period:

Repository	cron	everything else
Purchasely-Cordova	474 min	441 min
Purchasely-Flutter	433 min	562 min
Purchasely-ReactNative	324 min	380 min

The nightly is roughly half the macOS bill of that workflow, spent on a branch nobody touched. E2E Android runs on Linux with KVM, so it is far cheaper, but it is the same daily run with the same justification.

Changes

Both e2e-ios.yml and e2e-android.yml:

• schedule removed.
• pull_request no longer listens to synchronize: a push to an open pull request does not rebuild.
• pull_request now listens to opened, reopened, ready_for_review and labeled.
• Adding the run-ci label builds the current head. The first step removes the label again, because GitHub raises no labeled event for a label that is already present.
• workflow_dispatch is unchanged.

gh pr edit <number> --add-label run-ci

The existing paths filters still apply, so the label only starts a run on a pull request that actually touches the SDK or the example app.

Coverage this gives up

The nightlies were the only thing that exercised main after merge. Everything they covered still runs when a pull request opens, and on demand — one merge-time run less. There is no branch protection on main in this repository, so no check is required and nothing is blocked by a job that did not run.

Verification

The push that added the second commit to this branch is a synchronize event. Under the new configuration it started no run — that is the change working.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 4/5

The PR is not safe to merge until repeat on-request runs are made functional for fork pull requests.

Findings

1.  Fork labels remain attached ▶

Fix with agent prompt

### Issue 1
.github/workflows/e2e-ios.yml:62-64
For pull requests from forks, `github.token` is read-only, so this API call cannot delete the `run-ci` label. Because `continue-on-error` hides that failure, the label remains attached and cannot be re-added to generate another `labeled` event. As a result, the new on-request rebuild mechanism works only once for fork pull requests.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR reduces macOS CI consumption by removing the nightly iOS E2E schedule and automatic rebuilds on pull-request synchronization.

• Runs automatically when a pull request opens, reopens, or becomes ready for review.
• Adds run-ci label handling for requested rebuilds.
• Retains manual workflow dispatch.
• The label-consumption step cannot remove the label on fork pull requests, preventing repeat requested runs there.

_{Reviews (1) · Last reviewed commit: "chore(ci): drop the nightly E2E iOS run ..."}

[greptile-apps]

Fork labels remain attached

For pull requests from forks, github.token is read-only, so this API call cannot delete the run-ci label. Because continue-on-error hides that failure, the label remains attached and cannot be re-added to generate another labeled event. As a result, the new on-request rebuild mechanism works only once for fork pull requests.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/e2e-ios.yml
Line: 62-64

Comment:
**Fork labels remain attached**

For pull requests from forks, `github.token` is read-only, so this API call cannot delete the `run-ci` label. Because `continue-on-error` hides that failure, the label remains attached and cannot be re-added to generate another `labeled` event. As a result, the new on-request rebuild mechanism works only once for fork pull requests.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[kherembourg]

Fixed in 96654dc, in both e2e-ios.yml and e2e-android.yml — you reviewed cae0d62, before the Android workflow carried the same step.

The step now requires github.event.pull_request.head.repo.full_name == github.repository, so on a fork PR it no longer attempts a DELETE it cannot perform and continue-on-error has nothing to bury.

The premise is right; "works only once for fork pull requests" is not. A stuck label is removable from the PR sidebar, and removing then re-adding it raises a fresh labeled event. The real cost on a fork PR is one manual click. The comment above the step now says that.

For context on exposure here: this repository has no forks and has never taken a fork PR. The guard is in because the defect is real, not because it is currently reachable.