run-pr-e2e
Skill6 starsChanged 25 days agoMITView on GitHub
Android E2E for a PR using the CI-built APK (no local build). Verifies the bit-identical artifact that would ship. Defers to /run-e2e for everything generic.
- Reads credentials
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- benchSkill
- figma-implementSkill
- ios-routerSkill
- memory-profileSkill
- pmSkill
- review-l10nSkill
- review-prSkill
- run-e2eSkill
- start-taskSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 0 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 34
Always a fresh ./worktrees/PR-<N>-e2e on detached origin/<head-branch> — the exact commit CI built.
- Very specific: line 36
Never reuse an in-flight PR-<N> fix worktree (APK-vs-specs drift — the fix worktree may have uncommitted changes the CI APK doesn't know …
- Very specific: line 37
If PR-<N>-e2e already exists from a prior run, fast-forward it to current origin/<branch>.
- Very specific: line 42
Default is every *.spec.ts minus visual-capture, diagnostic, memory-profile, tts-memory-profile, benchmark-matrix:
- Very specific: line 96
Add --e2e if any spec in the list drives the automation bridge (memory-snapshot / bench-runner / AUTOMATION_BRIDGE).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Run PR E2E (CI APK)
This skill covers ONLY what's different from /run-e2e. For pre-flight (sim/emu booted, devices.json drift, port-4723 cleanup), reports, and failure-mode lookup — read /run-e2e. Do not duplicate.
When to use this vs /run-e2e
| You want | Use |
| Test local changes you're iterating on | /run-e2e |
| Verify a PR with the EXACT artifact that would ship (no local build divergence) | /run-pr-e2e |
| Run iOS E2E for a PR | /run-e2e (iOS CI doesn't publish a reusable sim build — you have to build from source) |
This skill is Android only. iOS is out of scope at the CI-artifact level.
What's different from /run-e2e
Four things. Everything else is the same and lives in /run-e2e.
1. Where the APK comes from
- Default (prod APK from
ci.yml).tools/run-pr-e2e.shcallstools/fetch-pr-apk.sh, which finds the newest completedci.ymlpull_requestrun for the PR, downloadsandroid-release-apk, and drops it at<worktree>/android/app/build/outputs/apk/release/app-release.apk. This APK is bridge-stripped — specs that drive thesrc/__automation__/bridge (memory-snapshot, bench-runner) silently no-op. --e2eflag (bridge-enabled APK frome2e-tests.yml). Required for bridge-driven specs. Dropped at<worktree>/android/app/build/outputs/apk/e2e/releaseE2e/app-e2e-releaseE2e.apk.e2e-tests.ymlisworkflow_dispatch-only and matched by head branch — it must have been dispatched for this PR's branch first (tools/ghb workflow run e2e-tests.yml --repo a-ghorbani/pocketpal-ai --ref <head-branch>), otherwise fetch fails with "no completed workflow_dispatch run found for branch".appPath. The wrapper rewrites every AndroidappPathine2e/devices.jsonto the path of the APK it fetched (or would fetch, with--no-fetch).
2. Worktree contract
Always a fresh ./worktrees/PR-<N>-e2e on detached origin/<head-branch> — the exact commit CI built. Rules:
- Never reuse an in-flight
PR-<N>fix worktree (APK-vs-specs drift — the fix worktree may have uncommitted changes the CI APK doesn't know about). - If
PR-<N>-e2ealready exists from a prior run, fast-forward it to currentorigin/<branch>; don't create a parallel one. ./tools/create-worktree.sh PR-<N>-e2e --detach --ref origin/<branch>already syncse2e/devices.json,.env, keystores. For an existing worktree refresh via./tools/sync-worktree-config.sh "$WORKTREE".
3. Spec selection
Default is every *.spec.ts minus visual-capture, diagnostic, memory-profile, tts-memory-profile, benchmark-matrix:
visual-capture— screenshot generation driven by story files, not a regression.diagnostic— device-state inspector, not a regression.memory-profile,tts-memory-profile— have their own pipeline (/memory-profile); need device-specific baselines to be meaningful.benchmark-matrix— has its own pipeline (/bench).
Enumerate dynamically so new specs on the PR are picked up:
EXCLUDE='^(visual-capture|diagnostic|memory-profile|tts-memory-profile|benchmark-matrix)$'
SPECS=$(find "$WORKTREE/e2e/specs" -type f -name '*.spec.ts' \
| sed -E 's#.*/##; s#\.spec\.ts$##' | grep -vE "$EXCLUDE" \
| sort -u | paste -sd, -)4. The entry point is tools/run-pr-e2e.sh, not the runner directly
It's a thin wrapper around scripts/run-e2e.ts --skip-build. It handles APK fetch + placement, then loops --specs invocations against the runner. Don't replicate its work by calling the runner directly — you'll re-download the APK or fight the wrapper.
Run
From the dev-team repo root:
ROOT="$PWD"
PR=<number>
PR_REF="refs/remotes/pr/$PR"
# Fetch the PR head into the submodule (read-only use; no cd into it; works for fork PRs)
git -C "$ROOT/repos/pocketpal-ai" fetch origin "+pull/$PR/head:$PR_REF"
# Create or fast-forward the e2e worktree (reset targets the worktree only)
if [ -d "./worktrees/PR-${PR}-e2e" ]; then
git -C "./worktrees/PR-${PR}-e2e" reset --hard "$PR_REF"
./tools/sync-worktree-config.sh "./worktrees/PR-${PR}-e2e"
else
./tools/create-worktree.sh "PR-${PR}-e2e" --detach --ref "$PR_REF"
fi
WORKTREE="./worktrees/PR-${PR}-e2e"
cd "$WORKTREE" && yarn install && (cd e2e && yarn install) && cd -
# Pre-flight: see /run-e2e Step 1 (phone claimed through agistry, emu/device attached, port 4723).
SPECS=$(find "$WORKTREE/e2e/specs" -type f -name '*.spec.ts' \
| sed -E 's#.*/##; s#\.spec\.ts$##' \
| grep -vE '^(visual-capture|diagnostic|memory-profile|tts-memory-profile|benchmark-matrix)$' \
| sort -u | paste -sd, -)
POCKETPAL_REPO="$(realpath "$WORKTREE")" \
bash ./tools/run-pr-e2e.sh "$PR" [--e2e] --specs "$SPECS" -- --devices connectedAdd --e2e if any spec in the list drives the automation bridge (memory-snapshot / bench-runner / AUTOMATION_BRIDGE).
Inputs that ONLY exist here (not in /run-e2e)
| Flag | Purpose |
--e2e | Fetch bridge-enabled APK from e2e-tests.yml (manual dispatch required) instead of prod APK from ci.yml |
--no-fetch | Skip APK download; reuse an already-installed APK on the device |
--specs a,b,c | Comma-separated list (one wrapper invocation per spec, sequentially) |
Everything after -- is passed verbatim to scripts/run-e2e.ts (devices filter, dry-run, etc.).
PR-specific failure modes (everything else: see /run-e2e)
| Symptom | Fix |
no completed CI runs found for PR #N | PR's ci.yml is still running or failed. gh run watch or pick another run. |
artifact 'android-release-apk' not found | The Android build job failed in that run. gh run view <id>. |
(--e2e) no completed e2e-tests.yml workflow_dispatch run found for branch | e2e-tests.yml was never dispatched for this PR's branch. Dispatch it (tools/ghb workflow run e2e-tests.yml --repo a-ghorbani/pocketpal-ai --ref <head-branch>), wait, then rerun. |
(--e2e) artifact 'e2e-android-apk' not found | E2E build job failed in that dispatch. gh run view <id>. |
Required env
GITHUB_TOKENorGH_TOKEN(for artifact download)ANDROID_HOMEorANDROID_SDK_ROOT
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

