home / skills / onekeyhq / app-monorepo / 1k-app-upgrade-test

1k-app-upgrade-test skill

/.claude/skills/1k-app-upgrade-test

This skill automates creation of test version branches and build configurations to validate app upgrade flows and version migrations.

npx playbooks add skill onekeyhq/app-monorepo --skill 1k-app-upgrade-test

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
2.8 KB
---
name: 1k-app-upgrade-test
description: Create test versions to verify app auto-update functionality and version migration.
allowed-tools: Read, Grep, Glob, Write, Edit, Bash
disable-model-invocation: true
---

# Test Version Creation

Automates creation of test version branches with hardcoded build configurations for testing app upgrade functionality and version migration flows.

## Quick Reference

### Version Pattern

Test versions follow the pattern: **`9XXX.YY.Z`**

- `9XXX` - Test version indicator (e.g., 9005)
- `YY.Z` - Matches production version being tested

Example: `9005.20.0` for testing production `5.20.0`

### Build Number Formula

Build number is calculated as:

```bash
DATE=$(date +%Y%m%d)
BUILD_NUMBER=$((${DATE}00 + 30))
```

**Format**: 10 digits = `YYYYMMDD00 + 30`

Example: If today is `20260130`, build number is `2026013030`

## Workflow

### Step 1: Get Version Information

Ask user for test version number:
- Format: `9XXX.YY.Z`
- Example: `9005.20.0`

### Step 2: Calculate Build Number

```bash
DATE=$(date +%Y%m%d)
BUILD_NUMBER=$((${DATE}00 + 30))
echo "Build number: $BUILD_NUMBER"
```

### Step 3: Create Branch

```bash
git checkout -b <test_version>
# Example: git checkout -b 9005.20.0
```

### Step 4: Modify Configuration Files

Update these files in order:

1. **`.env.version`**
   - Set VERSION to test version
   - Set BUILD_NUMBER to calculated value

2. **`.github/actions/shared-env/action.yml`**
   - Update version in outputs section

3. **`.github/workflows/release-android.yml`**
   - Update versionName in android-build job

4. **`apps/mobile/android/app/build.gradle`**
   - Update versionCode
   - Update versionName

### Step 5: Commit and Push

```bash
git add .
git commit -m "chore: create test version <version>"
git push origin <test_version>
```

## Files to Modify

| File | What to Update |
|------|----------------|
| `.env.version` | VERSION, BUILD_NUMBER |
| `.github/actions/shared-env/action.yml` | outputs.version |
| `.github/workflows/release-android.yml` | versionName |
| `apps/mobile/android/app/build.gradle` | versionCode, versionName |

## Detailed Guide

For comprehensive test version creation workflow with examples, see [upgrade-test-version.md](references/rules/upgrade-test-version.md).

Topics covered:
- Version number format and conventions
- Build number calculation formula
- Step-by-step file modification instructions
- Configuration file examples
- Git workflow for test versions
- QA testing considerations

## When to Use This Skill

- Creating test builds for QA upgrade testing
- Testing version migration flows
- Verifying app upgrade functionality
- Creating release candidates with specific build numbers
- Testing version-specific features or fixes

## Related Skills

- `/1k-git-workflow` - Git branching conventions
- `/1k-dev-commands` - Build and release commands

Overview

This skill automates creating test release branches and hardcoded build configurations to validate app auto-update and version migration flows. It standardizes test version naming, computes a deterministic build number, and updates the minimal set of configuration files needed to produce test installs. Use it to generate repeatable QA builds that mimic production upgrades without affecting production artifacts.

How this skill works

You supply a test version following the 9XXX.YY.Z pattern (for example, 9005.20.0). The skill computes a 10-digit build number from the current date (YYYYMMDD00 + 30), creates a new Git branch, and updates four configuration files with the test version and calculated build number. Finally it commits and pushes the branch so CI or QA can build and install the test package for upgrade/migration checks.

When to use it

  • When you need a repeatable test build to verify upgrade or migration flows
  • Before QA runs upgrade scenarios between a production release and a test install
  • To validate auto-update behavior in mobile CI pipelines
  • When creating release candidates that must carry a known build number
  • To reproduce version-specific bug reports in a controlled test channel

Best practices

  • Follow the 9XXX.YY.Z naming convention so test versions clearly map to production versions
  • Run the build-number calculation at branch creation time to avoid collisions across days
  • Edit configuration files in the specified order (.env.version → shared action → workflow → android gradle) to keep CI outputs consistent
  • Use a descriptive commit message like "chore: create test version <version>" and push the branch to origin for CI to pick up
  • Keep test branches short-lived and document their purpose in the branch name or commit body

Example use cases

  • Create 9005.20.0 to test an upgrade path from production 5.20.0 to a test build
  • Generate a dated build number for QA to validate Android versionCode/versionName changes
  • Reproduce a migration failure reported on a specific production version by using an exact test-version branch
  • Run automated QA that installs the test APK from CI and verifies data migration logic after update

FAQ

What is the required test version format?

Use 9XXX.YY.Z where 9XXX identifies a test version (for example 9005) and YY.Z matches the production version being tested.

How is the build number calculated?

Build number = YYYYMMDD00 + 30. For example, 20260130 → 2026013030.