Testers Orchestration for Google Play

Use this skill to assign testers to a track and promote builds through the testing funnel. All tester changes happen inside an edit session and take effect only after gplay edits commit.

Testing tracks

alpha is a closed track (invite-only), not public. Testers on internal and closed tracks are managed by email address or by Google Group.

Tester commands

gplay testers has only three subcommands. There is no testers list — to list the testers on a track, use testers get.

• gplay testers get — read the testers on a track.
• gplay testers update — replace the entire tester set (emails/groups not included are removed).
• gplay testers patch — merge with the existing set (preserves fields you omit).

List (get) testers for a track

gplay testers get \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha

Assign testers (replace the whole set)

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "tester1@example.com,tester2@example.com"

By Google Group instead of individual emails:

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --google-groups "beta-testers@example.com,qa-team@example.com"

Add testers without dropping existing ones (patch)

gplay testers patch \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "newtester@example.com"

Remove a tester (update = replace with the reduced set)

update replaces the resource, so re-send only the testers you want to keep:

CURRENT=$(gplay testers get --package com.example.app --edit $EDIT_ID --track alpha \
  | jq -r '.testers[]?')
KEEP=$(echo "$CURRENT" | grep -v "user@example.com" | paste -sd "," -)

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "$KEEP"

Assign testers inside an edit session (canonical flow)

Tester assignment is not a flag on gplay release. There is no --testers flag anywhere. The real flow is an edit session:

# 1. Create an edit
EDIT_ID=$(gplay edits create --package com.example.app | jq -r '.id')

# 2. Upload the build
gplay bundles upload \
  --package com.example.app \
  --edit $EDIT_ID \
  --file app-release.aab

# 3. Assign the release to the track
gplay tracks update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --releases '[{"versionCodes":["123"],"status":"completed"}]'

# 4. Assign testers to the track
gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "tester1@example.com,tester2@example.com"

# 5. Commit (nothing applies until this succeeds)
gplay edits commit --package com.example.app --edit $EDIT_ID

Create a closed testing track

Custom closed tracks are created inside an edit, then get testers assigned the same way:

EDIT_ID=$(gplay edits create --package com.example.app | jq -r '.id')

gplay tracks create \
  --package com.example.app \
  --edit $EDIT_ID \
  --track qa-ring

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track qa-ring \
  --emails "qa1@example.com,qa2@example.com"

gplay edits commit --package com.example.app --edit $EDIT_ID

Promote a build between tracks

Promotion copies the source track's version codes to a destination track. --rollout is a fraction (0.0–1.0), not a percentage:

# Internal -> closed alpha
gplay promote --package com.example.app --from internal --to alpha

# Closed beta -> production at 10% staged rollout
gplay promote --package com.example.app --from beta --to production --rollout 0.1

Agent behavior

• There is no testers list subcommand; use gplay testers get --track <track> to read a track's testers.
• Never pass --testers to gplay release; assign testers via testers update/patch inside an edit, then commit.
• Use update to set the exact tester set, patch to add without removing.
• --rollout values are fractions (0.1 = 10%), range 0.0–1.0.
• Always gplay edits commit — tester changes are inert until committed.
• Confirm flags with --help before running.