Gpc Ci Integration

GPC CI Integration

When to use

Use this skill when the task involves:

• Setting up GPC in GitHub Actions, GitLab CI, Bitbucket Pipelines, or CircleCI
• Automating Play Store releases from CI/CD
• Configuring environment variables for CI authentication
• Using GPC's JSON output for scripting and automation
• Implementing vitals-gated rollouts in CI
• Building release pipelines with upload → promote → monitor flows
• Using --dry-run for safe CI testing

Inputs required

• CI platform (GitHub Actions, GitLab CI, Bitbucket, CircleCI, or generic)
• Auth method (usually service account via env var)
• Release workflow: upload only, upload + promote, or full pipeline
• Whether vitals gating is desired
• Package name of the Android app

Procedure

Quickest path: GPC GitHub Action (v0.9.81+)

For GitHub Actions users, the GPC GitHub Action is the fastest way to publish to the Play Store. No Node.js setup step, no manual install, no wrapper script.

Available on the GitHub Actions Marketplace.

Minimal usage:

- uses: yasserstudio/gpc-action@v1
  with:
    service-account-json: ${{ secrets.GPC_SERVICE_ACCOUNT }}
    package-name: com.example.app
    release-file: app/build/outputs/bundle/release/app-release.aab
    track: internal

One step replaces the full install + run + cleanup sequence. The action runs a built-in preflight compliance gate before uploading, so non-compliant AABs are rejected before they reach the Play API.

Migrating from `r0adkll/upload-google-play`? It is a drop-in replacement. The input names are the same; change one line:

# Before:
- uses: r0adkll/upload-google-play@v1

# After:
- uses: yasserstudio/gpc-action@v1

The action is a TypeScript action running on Node 24. No additional configuration is required for the migration.

For advanced pipelines (multi-step, vitals gating, changelog generation), continue with the manual workflow patterns below.

0) CI environment behavior

GPC auto-detects CI environments:

• Output: Defaults to JSON when stdout is not a TTY (piped or CI)
• Interactive: Prompts are disabled automatically when CI=true
• Colors: Disabled in non-TTY environments
• Plugin-CI: Writes GitHub Actions step summaries when $GITHUB_STEP_SUMMARY is available

Environment variables for CI override:

GPC_NO_INTERACTIVE=1   # Explicitly disable prompts
GPC_NO_COLOR=1         # Explicitly disable colors
GPC_OUTPUT=json        # Force JSON output

Config resolution precedence (v0.9.81+): CLI flags override env vars, which override the active profile, which overrides .gpcrc.json, which falls back to defaults.

--service-account / --app flags  (highest priority)
  GPC_SERVICE_ACCOUNT / GPC_APP env vars
    active profile (gpc auth switch <name>)
      .gpcrc.json
        defaults

Prior to v0.9.81, an active profile silently won over GPC_SERVICE_ACCOUNT/GPC_APP env vars. This is now fixed. If your CI sets GPC_SERVICE_ACCOUNT and a profile is also active, the env var takes effect as expected.

1) GitHub Actions

Minimal — upload to internal track:

name: Upload to Play Store
on:
  push:
    tags: ['v*']
  workflow_dispatch: {}

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build AAB
        run: ./gradlew bundleRelease

      - name: Install GPC
        run: npm install -g @gpc-cli/cli --ignore-scripts

      - name: Upload to Play Store
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
          GPC_APP: com.example.app
        run: |
          gpc releases upload app/build/outputs/bundle/release/app-release.aab \
            --track internal \
            --changes-not-sent-for-review

Full pipeline — upload, check vitals, promote:

name: Release Pipeline
on:
  workflow_dispatch:
    inputs:
      track:
        description: 'Target track'
        default: 'beta'
      rollout:
        description: 'Rollout percentage'
        default: '100'

jobs:
  release:
    runs-on: ubuntu-latest
    env:
      GPC_APP: com.example.app
    steps:
      - uses: actions/checkout@v4

      - name: Install GPC
        run: npm install -g @gpc-cli/cli --ignore-scripts

      - name: Preflight compliance check
        run: gpc preflight app-release.aab --fail-on error --json

      - name: Upload release
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
        run: |
          gpc releases upload app-release.aab \
            --track ${{ inputs.track }} \
            --rollout ${{ inputs.rollout }} \
            --changes-not-sent-for-review \
            --mapping-type PROGUARD \
            --device-tier-config default

      - name: Error if in review
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
        run: gpc releases status --error-if-in-review

      - name: Check vitals
        if: inputs.track == 'production'
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
        run: |
          gpc vitals crashes --threshold 2.0
          gpc vitals anr --threshold 0.47

      - name: Release status
        if: always()
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
        run: gpc releases status --output markdown >> $GITHUB_STEP_SUMMARY

      - name: Generate GitHub Release notes
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: gpc changelog generate | gh release create ${{ github.ref_name }} -F -
        # Requires GPC v0.9.61+. --strict flag available to fail CI on jargon.

Read:

• references/github-actions.md

2) GitLab CI

release:
  image: node:22
  stage: deploy
  variables:
    GPC_SERVICE_ACCOUNT: $PLAY_SERVICE_ACCOUNT
    GPC_APP: com.example.app
  script:
    - npm install -g @gpc-cli/cli
    - gpc releases upload app-release.aab --track internal --changes-not-sent-for-review
  only:
    - tags

3) Bitbucket Pipelines

pipelines:
  tags:
    'v*':
      - step:
          name: Upload to Play Store
          image: node:22
          script:
            - npm install -g @gpc-cli/cli
            - gpc releases upload app-release.aab --track internal --changes-not-sent-for-review
          deployment: production

4) CircleCI

jobs:
  release:
    docker:
      - image: cimg/node:22.0
    steps:
      - checkout
      - run:
          name: Upload to Play Store
          command: |
            npm install -g @gpc-cli/cli
            gpc releases upload app-release.aab --track internal --changes-not-sent-for-review
          environment:
            GPC_APP: com.example.app

5) Using standalone binary (no Node.js)

For minimal CI images without Node.js:

- name: Install GPC binary
  run: curl -fsSL https://raw.githubusercontent.com/yasserstudio/gpc/main/scripts/install.sh | bash

- name: Upload
  run: gpc releases upload app-release.aab --track internal

6) Output formats for CI scripting

GPC auto-outputs JSON in CI (non-TTY). Parse with jq:

JUnit output caveat: --output junit is available but testcase name attributes use generic identifiers (item-1, item-2) for some commands (tracks list, releases status). Prefer --output json | jq for reliable CI parsing. Use --output junit only if your test reporter specifically requires JUnit XML format.

CSV/TSV output (v0.9.68+): All commands support --output csv and --output tsv for spreadsheet-friendly or tab-delimited parsing without requiring jq:

# Export release status as CSV (headers on first line)
gpc releases status --output csv > releases.csv

# TSV for awk / cut parsing in shell scripts
gpc vitals crashes --output tsv | awk -F'\t' '{print $2}'

# Force a specific format regardless of TTY detection
GPC_OUTPUT=csv gpc apps list

Use CSV/TSV when piping into tools like csvkit, mlr, or spreadsheet imports. Use JSON when you need nested structure or when piping into jq.

# Get version code from upload result
VERSION=$(gpc releases upload app.aab --track beta | jq -r '.data.versionCode')

# Check if vitals are OK
CRASH_RATE=$(gpc vitals crashes --output json | jq -r '.data.crashRate')

# Conditional promotion
if (( $(echo "$CRASH_RATE < 2.0" | bc -l) )); then
  gpc releases promote --from beta --to production --rollout 10
fi

7) Exit codes for CI logic

- name: Check vitals
  run: gpc vitals crashes --threshold 2.0
  continue-on-error: false  # Exit code 6 fails the job

8) Vitals-gated rollout pattern

- name: Upload to beta
  run: |
    gpc publish app.aab --track beta \
      --changes-not-sent-for-review \
      --mapping-type PROGUARD

- name: Wait for crash data
  run: sleep 3600  # Wait 1 hour for crash data

- name: Gate on vitals
  run: |
    gpc vitals crashes --threshold 2.0
    gpc vitals anr --threshold 0.47

- name: Promote to production
  run: gpc releases promote --from beta --to production --rollout 10

Wait for bundle processing before promoting (v0.9.69+)

After uploading a large AAB, bundle processing on Google's side can take 30–120 seconds. Use gpc bundles wait as an explicit gate instead of relying on the built-in Fibonacci polling inside gpc publish:

- name: Upload AAB
  run: |
    gpc releases upload app-release.aab \
      --track internal \
      --changes-not-sent-for-review

- name: Wait for bundle processing
  run: gpc bundles wait --version-code ${{ env.VERSION_CODE }}
  # Exits 0 when ACTIVE, non-zero on timeout or error.
  # Prevents INVALID_ARGUMENT errors when promoting before processing completes.

- name: Promote to beta
  run: gpc releases promote --from internal --to beta

This is especially useful in multi-job pipelines where upload and promote run in separate jobs.

Gate Play Store release notes on character budget (v0.9.62+)

      - name: Verify all locales fit Play Store 500-char budget
        run: |
          gpc changelog generate --target play-store \
            --locales auto \
            --app com.example.app \
            --strict
        # --strict exits 1 if any locale overflows; collects all overflows in one report.

Translate release notes on every tag (v0.9.63+)

      - name: Generate + translate Play Store release notes
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          # Or OPENAI_API_KEY / GOOGLE_GENERATIVE_AI_API_KEY / AI_GATEWAY_API_KEY
        run: |
          gpc changelog generate --target play-store \
            --locales auto \
            --app com.example.app \
            --ai \
            --strict \
            --format json > release-notes.json
        # --strict exits 1 if any locale fails to translate or overflows 500 chars.
        # --format json emits the `ai` block (provider, model, tokensIn, tokensOut,
        # plus runId + costUsd on the Gateway path) for log aggregation.

Write translated notes into a Play Store draft (v0.9.64+)

      - name: Write translated release notes into Play Store draft
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          gpc changelog generate --target play-store \
            --locales auto \
            --ai \
            --apply \
            --track production
        # --apply writes the result into the latest draft release on the track.
        # Requires a draft release to exist on the target track.
        # Exits with RELEASE_NO_DRAFT (code 1) if no draft found.

9) Dry-run for testing pipelines

Test your CI pipeline without making real changes:

- name: Test release pipeline (dry-run)
  run: |
    gpc releases upload app.aab --track beta --dry-run
    gpc releases promote --from beta --to production --rollout 10 --dry-run

9a) Handling rejected apps in CI

When Google Play rejects an app update, gpc releases status reports the rejection reason. Use --error-if-in-review to detect and handle in-review or rejected states in your pipeline:

- name: Check for rejection
  id: review-check
  run: gpc releases status --error-if-in-review
  continue-on-error: true

- name: Handle rejection
  if: steps.review-check.outcome == 'failure'
  run: |
    echo "Release was rejected or is still in review."
    echo "Check the Play Console for details."
    gpc releases status --output json | jq '.data.releases[] | select(.status == "rejected")'
    exit 1

The --error-if-in-review flag exits with code 4 if any release on the target track is in inReview or rejected status. Use this before uploading a new version to avoid EDIT_CONFLICT errors when a previous submission is still pending review.

10) Markdown output for GitHub step summaries

gpc releases status --output markdown >> $GITHUB_STEP_SUMMARY
gpc vitals overview --output markdown >> $GITHUB_STEP_SUMMARY

11) Supply chain security in CI

GPC's own CI uses 12 protection layers. When integrating GPC into your pipeline, follow these practices:

# Pin GPC version (don't rely on @latest in production)
- run: npm install -g @gpc-cli/cli@0.9.82 --ignore-scripts

# Or use the standalone binary (no npm supply chain risk)
- run: curl -fsSL https://raw.githubusercontent.com/yasserstudio/gpc/main/scripts/install.sh | bash

# Pin GitHub Actions to commit SHAs
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd  # v6

--ignore-scripts on all pnpm/npm install commands (v0.9.74+)

All CI pnpm install and npm install commands must use --ignore-scripts to block lifecycle-script execution by untrusted packages. GPC's own pnpm.onlyBuiltDependencies is set to ["turbo", "esbuild"] in package.json — only those two packages are permitted to run install scripts.

- name: Install dependencies
  run: pnpm install --frozen-lockfile --ignore-scripts

Lockfile integrity verification (v0.9.74+)

Verify pnpm-lock.yaml has not been tampered with before installing:

- name: Verify lockfile integrity
  run: |
    sha256sum pnpm-lock.yaml > /tmp/lockfile.sha256
    # Compare against the known-good SHA stored as a repo secret or artifact
    echo "${{ secrets.LOCKFILE_SHA256 }}  pnpm-lock.yaml" | sha256sum -c -

Step-scoped secrets (v0.9.74+)

Never set GPC_SERVICE_ACCOUNT at the job level. Always scope it to the specific step that needs it:

# WRONG — secret is available to every step in the job
jobs:
  release:
    env:
      GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}

# CORRECT — secret only visible to the upload step
- name: Upload release
  env:
    GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
  run: gpc releases upload app-release.aab --track internal

Deep security scan (v0.9.74+)

GPC ships a pnpm security:deep script that runs deepsec scanning across all packages. Add it to your release pipeline:

- name: Deep security scan
  run: pnpm security:deep

workflow_dispatch trigger for manual re-runs (v0.9.74+)

Add workflow_dispatch: {} to every release workflow so engineers can re-trigger failed runs without creating a new tag:

on:
  push:
    tags: ['v*']
  workflow_dispatch: {}

For Socket.dev scanning on your own repo, add socket ci to your workflow:

- name: Socket Security Scan
  run: |
    npm install -g socket@latest --ignore-scripts
    socket ci --repo your-repo
  env:
    SOCKET_SECURITY_API_TOKEN: ${{ secrets.SOCKET_SECURITY_API_TOKEN }}

12) APK uploads

GPC auto-detects the file format and uses the correct API endpoint:

# AAB upload (recommended)
- run: gpc releases upload app-release.aab --track internal

# APK upload (auto-detected)
- run: gpc releases upload app-release.apk --track internal

# Draft release (not visible to users until explicitly released)
- run: gpc releases upload app-release.aab --track production --status draft

13) Retry and timeout configuration

env:
  GPC_MAX_RETRIES: '5'
  GPC_TIMEOUT: '60000'
  GPC_BASE_DELAY: '2000'
  GPC_MAX_DELAY: '120000'
  GPC_RATE_LIMIT: '50'

Use --retry-log to debug transient failures:

gpc releases upload app.aab --track beta --retry-log retries.log

Verification

• CI job completes with exit code 0
• gpc releases status (in subsequent step) confirms release is on expected track
• GitHub Actions step summary shows release details
• Vitals check exits 0 (below threshold) or 6 (above threshold) as expected

Failure modes / debugging

Read:

• references/troubleshooting.md

Related skills

• gpc-setup: Initial authentication and configuration
• gpc-release-flow: Release commands and rollout management
• gpc-vitals-monitoring: Vitals metrics and review management
• gpc-metadata-sync: Store listing automation

Bitbucket Pipelines Templates for GPC

Ready-to-use bitbucket-pipelines.yml configurations for GPC.

Authentication setup

Store your service account JSON as a Bitbucket repository variable:

1. Go to Repository settings > Pipelines > Repository variables 2. Add variable PLAY_SA_KEY with the JSON content 3. Check Secured to encrypt it

Basic upload on tag

image: node:20

pipelines:
  tags:
    'v*':
      - step:
          name: Upload to internal
          script:
            - npm install -g @gpc-cli/cli
            - gpc validate app-release.aab
            - gpc releases upload app-release.aab --track internal --changes-not-sent-for-review
          artifacts:
            - '*.log'

Set GPC_SERVICE_ACCOUNT and GPC_APP as repository variables.

Full pipeline with manual promotion

image: node:20

definitions:
  steps:
    - step: &install-gpc
        name: Install GPC
        script:
          - npm install -g @gpc-cli/cli
          - gpc --version

pipelines:
  tags:
    'v*':
      - step:
          name: Upload to beta
          script:
            - npm install -g @gpc-cli/cli
            - gpc releases upload app-release.aab --track beta --changes-not-sent-for-review
      - step:
          name: Check vitals
          trigger: manual
          script:
            - npm install -g @gpc-cli/cli
            - gpc vitals crashes --threshold 1.5
            - gpc vitals anr --threshold 0.4
      - step:
          name: Promote to production
          trigger: manual
          script:
            - npm install -g @gpc-cli/cli
            - gpc releases promote --from beta --to production --rollout 10

Scheduled vitals check

pipelines:
  custom:
    vitals-check:
      - step:
          name: Check app vitals
          script:
            - npm install -g @gpc-cli/cli
            - gpc vitals overview --json
            - gpc vitals crashes --threshold 2.0
            - gpc vitals anr --threshold 0.5

Trigger via Bitbucket Schedules: Pipelines > Schedules > Add schedule and select the vitals-check custom pipeline.

Environment variables

Set these as repository variables (all secured):

Tips

• Use trigger: manual for promotion steps
• Bitbucket has a 120-minute step timeout — set GPC_TIMEOUT well under this
• Use artifacts to save logs and reports
• Secured variables are not available in PRs from forks (security feature)
• Use definitions for reusable step templates

GitHub Actions Integration

Authentication Setup

1. Create a repository secret:

• Go to repo → Settings → Secrets and variables → Actions
• Add PLAY_SERVICE_ACCOUNT containing the service account JSON content

2. Reference in workflow — step-scoped only (v0.9.74+):

   # Scope GPC_SERVICE_ACCOUNT to the specific upload step, not the job
   - name: Upload release
     env:
       GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
     run: gpc releases upload app-release.aab --track internal

Never set GPC_SERVICE_ACCOUNT at the jobs.<job>.env level — this exposes the secret to every step including third-party actions.

Workflow Templates

Upload on Tag Push

name: Release to Play Store
on:
  push:
    tags: ['v*']
  workflow_dispatch: {}

jobs:
  release:
    runs-on: ubuntu-latest
    env:
      GPC_APP: com.example.app
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17

      - name: Build AAB
        run: ./gradlew bundleRelease

      - name: Install GPC
        run: npm install -g @gpc-cli/cli --ignore-scripts

      - name: Upload to internal track
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
        run: |
          gpc publish \
            app/build/outputs/bundle/release/app-release.aab \
            --track internal \
            --notes "Release ${GITHUB_REF_NAME}" \
            --changes-not-sent-for-review

      - name: Release summary
        if: always()
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
        run: gpc releases status --output markdown >> $GITHUB_STEP_SUMMARY

Manual Release with Inputs

name: Manual Release
on:
  workflow_dispatch:
    inputs:
      track:
        description: Target track
        type: choice
        options: [internal, alpha, beta, production]
        default: internal
      rollout:
        description: Rollout percentage (production only)
        type: number
        default: 100
      dry_run:
        description: Dry run (preview only)
        type: boolean
        default: false

jobs:
  release:
    runs-on: ubuntu-latest
    env:
      GPC_APP: com.example.app
    steps:
      - uses: actions/checkout@v4

      - name: Install GPC
        run: npm install -g @gpc-cli/cli --ignore-scripts

      - name: Upload release
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
        run: |
          FLAGS=""
          if [ "${{ inputs.dry_run }}" = "true" ]; then
            FLAGS="--dry-run"
          fi
          gpc releases upload app-release.aab \
            --track ${{ inputs.track }} \
            --rollout ${{ inputs.rollout }} \
            --changes-not-sent-for-review \
            $FLAGS

Scheduled Vitals Check

name: Vitals Monitor
on:
  schedule:
    - cron: '0 9 * * 1-5'  # Weekdays at 9am UTC
  workflow_dispatch: {}

jobs:
  check:
    runs-on: ubuntu-latest
    env:
      GPC_APP: com.example.app
    steps:
      - name: Install GPC
        run: npm install -g @gpc-cli/cli --ignore-scripts

      - name: Vitals dashboard
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
        run: gpc vitals overview --output markdown >> $GITHUB_STEP_SUMMARY

      - name: Check thresholds
        env:
          GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SERVICE_ACCOUNT }}
        run: |
          gpc vitals crashes --threshold 2.0
          gpc vitals anr --threshold 0.47

Step Summary Output

GPC supports --output markdown which works perfectly with $GITHUB_STEP_SUMMARY:

# Add release status to step summary
gpc releases status --output markdown >> $GITHUB_STEP_SUMMARY

# Add vitals dashboard to step summary
gpc vitals overview --output markdown >> $GITHUB_STEP_SUMMARY

# Add review summary
gpc reviews list --stars 1-2 --since 7d --output markdown >> $GITHUB_STEP_SUMMARY

Plugin-CI Integration

GPC's @gpc-cli/plugin-ci automatically detects GitHub Actions and writes step summaries:

• After each command: markdown table with app, duration, exit code
• On errors: error details with code and message

This happens automatically — no configuration needed.

Concurrency Control

Prevent parallel releases to the same app:

concurrency:
  group: play-store-release-${{ github.ref }}
  cancel-in-progress: false  # Don't cancel running releases

Caching GPC

Speed up workflows by caching GPC installation:

- name: Cache GPC
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: gpc-${{ hashFiles('**/package-lock.json') }}

- name: Install GPC
  run: npm install -g @gpc-cli/cli

GitLab CI Templates for GPC

Ready-to-use .gitlab-ci.yml configurations for GPC.

Authentication setup

Store your service account JSON as a GitLab CI/CD variable:

1. Go to Settings > CI/CD > Variables 2. Add variable PLAY_SA_KEY with the JSON content 3. Set type to Variable (not File) 4. Mark as Protected and Masked if possible

Basic upload on tag

stages:
  - deploy

upload-to-internal:
  stage: deploy
  image: node:20
  only:
    - tags
  variables:
    GPC_SERVICE_ACCOUNT: $PLAY_SA_KEY
    GPC_APP: com.example.app
  before_script:
    - npm install -g @gpc-cli/cli
  script:
    - gpc validate app/build/outputs/bundle/release/app-release.aab
    - gpc releases upload app/build/outputs/bundle/release/app-release.aab --track internal --changes-not-sent-for-review

Full pipeline with promotion

stages:
  - upload
  - verify
  - promote

variables:
  GPC_SERVICE_ACCOUNT: $PLAY_SA_KEY
  GPC_APP: com.example.app
  GPC_MAX_RETRIES: "5"
  GPC_TIMEOUT: "120000"

upload-beta:
  stage: upload
  image: node:20
  only:
    - tags
  before_script:
    - npm install -g @gpc-cli/cli
  script:
    - gpc releases upload app-release.aab --track beta --changes-not-sent-for-review
    - echo "Uploaded to beta"

check-vitals:
  stage: verify
  image: node:20
  only:
    - tags
  when: delayed
  start_in: "24 hours"
  before_script:
    - npm install -g @gpc-cli/cli
  script:
    - gpc vitals crashes --threshold 1.5
    - gpc vitals anr --threshold 0.4
  allow_failure: false

promote-production:
  stage: promote
  image: node:20
  only:
    - tags
  when: manual
  before_script:
    - npm install -g @gpc-cli/cli
  script:
    - gpc releases promote --from beta --to production --rollout 10
    - echo "Promoted to production at 10%"

Scheduled vitals check

vitals-report:
  image: node:20
  only:
    - schedules
  variables:
    GPC_SERVICE_ACCOUNT: $PLAY_SA_KEY
    GPC_APP: com.example.app
  before_script:
    - npm install -g @gpc-cli/cli
  script:
    - gpc vitals overview --json > vitals.json
    - gpc vitals crashes --threshold 2.0
    - gpc vitals anr --threshold 0.5
  artifacts:
    paths:
      - vitals.json
    expire_in: 30 days

IAP sync on merge to main

sync-iap:
  stage: deploy
  image: node:20
  only:
    - main
  changes:
    - products/**/*.json
  variables:
    GPC_SERVICE_ACCOUNT: $PLAY_SA_KEY
    GPC_APP: com.example.app
  before_script:
    - npm install -g @gpc-cli/cli
  script:
    - gpc iap sync --dir products/ --dry-run
    - gpc iap sync --dir products/

Tips

• Use when: delayed with start_in for time-gated stages
• Use when: manual for promotion steps that need human approval
• Use changes: to run IAP/metadata sync only when relevant files change
• Set GPC_MAX_RETRIES and GPC_TIMEOUT as global variables for shared runners
• Use artifacts to save vitals reports and upload logs

CI Troubleshooting

Authentication Failures

AUTH_INVALID in CI

Most common cause: Secret not set correctly.

Debug steps:

- name: Verify secret exists
  run: |
    if [ -z "$GPC_SERVICE_ACCOUNT" ]; then
      echo "ERROR: GPC_SERVICE_ACCOUNT is not set"
      exit 1
    fi
    echo "Secret length: ${#GPC_SERVICE_ACCOUNT}"

Common mistakes: 1. Secret name mismatch (PLAY_SERVICE_ACCOUNT vs GPC_SERVICE_ACCOUNT) 2. Secret contains file path instead of JSON content 3. JSON is truncated (check character limit on CI platform) 4. Wrong env var name in workflow

Permission denied

Service account exists but lacks Play Console permissions.

Fix: 1. Play Console → Settings → API access 2. Find service account → Manage → check permissions 3. Ensure "Release to production" is granted (if deploying to production)

Upload Issues

Timeout on large AAB

env:
  GPC_TIMEOUT: '120000'  # 2 minutes
  GPC_MAX_RETRIES: '5'

EDIT_CONFLICT in parallel jobs

Two jobs trying to modify the same app simultaneously.

Fix: Add concurrency control:

concurrency:
  group: play-store-${{ env.GPC_APP }}
  cancel-in-progress: false

Version code already used

CI built the same version code twice.

Fix: Ensure version code is unique per build:

// build.gradle
android {
    defaultConfig {
        versionCode System.getenv("GITHUB_RUN_NUMBER")?.toInteger() ?: 1
    }
}

Network Issues

Rate limiting (429 errors)

env:
  GPC_BASE_DELAY: '2000'
  GPC_MAX_DELAY: '120000'
  GPC_MAX_RETRIES: '5'
  GPC_RATE_LIMIT: '30'  # Reduce from default 50

Proxy required

env:
  HTTPS_PROXY: ${{ secrets.PROXY_URL }}
  GPC_CA_CERT: /path/to/ca-bundle.crt

Exit Code Reference

Use exit codes for conditional CI logic:

- name: Check vitals
  id: vitals
  run: gpc vitals crashes --threshold 2.0
  continue-on-error: true

- name: Promote (only if vitals OK)
  if: steps.vitals.outcome == 'success'
  run: gpc releases promote --from beta --to production

- name: Alert (if vitals bad)
  if: steps.vitals.outcome == 'failure'
  run: echo "Vitals threshold breached — promotion blocked"

Rejected or In-Review Releases

If a previous submission is still in review or was rejected, uploading a new version may fail with EDIT_CONFLICT.

Detect before uploading:

- name: Check for pending review
  run: gpc releases status --error-if-in-review

The --error-if-in-review flag exits with code 4 if any release is in inReview or rejected status. Handle it before uploading:

- name: Check for pending review
  id: review-check
  run: gpc releases status --error-if-in-review
  continue-on-error: true

- name: Upload release
  if: steps.review-check.outcome == 'success'
  run: gpc releases upload app.aab --track beta --changes-not-sent-for-review

If a release was rejected, resolve the issue in the Play Console before re-uploading from CI.

Debugging with Verbose Output

- name: Upload with debug logging
  run: gpc releases upload app.aab --track beta --verbose --retry-log retries.log

- name: Upload retry log
  if: failure()
  uses: actions/upload-artifact@v4
  with:
    name: retry-log
    path: retries.log

Platform-Specific Notes

GitLab CI

• Use $CI_JOB_TOKEN for artifact access, but GPC_SERVICE_ACCOUNT for Play Store
• Variables set in Settings → CI/CD → Variables

Bitbucket Pipelines

• Secrets set in Repository Settings → Pipelines → Repository Variables
• Max secret size is 32KB — base64 encode if needed

CircleCI

• Use Contexts for shared secrets across projects
• Environment variables in Project Settings → Environment Variables