mcpField
G
gplay-testers-orchestration

gplay-testers-orchestration

github.com/tamtomTesting & quality52360 installsUpdated 13w ago
Repository

About gplay-testers-orchestration

A skill for managing Google Play testing tracks and moving builds between them with the gplay CLI. It is for teams handling app testing and releases; tester changes take effect only after an edit session is committed.

Key features

  1. 01Read testers on a track
  2. 02Replace or add to tester lists
  3. 03Assign by email or Google Group
  4. 04Create closed testing tracks
  5. 05Promote builds between tracks

Use cases

  1. 01Review testers on the alpha track
  2. 02Add testers while retaining existing ones
  3. 03Create a closed QA testing track
  4. 04Promote a beta build to production

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/tamtom/gplay-cli-skills --skill gplay-testers-orchestration

After installing, type/gplay-testers-orchestrationin Claude Code to confirm it loaded.

Details

From the project README

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

TrackTypeMax testersReviewAccess
internalInternal100NoInstant
alphaClosed testingUnlimitedNoMinutes
betaOpen or closed testingUnlimitedNo/YesMinutes
custom trackClosed testingUnlimitedNoMinutes
productionPublicUnlimitedYesDays

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 "[email protected],[email protected]"

By Google Group instead of individual emails:

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --google-groups "[email protected],[email protected]"
Add testers without dropping existing ones (patch)
gplay testers patch \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "[email protected]"
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 "[email protected]" | 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 "[email protected],[email protected]"

# 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 "[email protected],[email protected]"

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.

Comments

Markdown supported