agentsclimarketplace

Mobile ci cd

Skill tinh2/skills-hub-registry/deploy/mobile-ci-cd

Open registry of community-contributed AI coding skills (SKILL.md files) — daily-synced to skills-hub.ai. Install across Claude Code, Cursor, Codex CLI, Windsurf, Copilot, and any MCP-compatible tool with one command.

Install
npx -y skills add tinh2/skills-hub-registry --skill mobile-ci-cd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Set up mobile CI/CD pipelines for Flutter, React Native, or native iOS/Android — GitHub Actions workflows for testing, code signing, TestFlight/Play Store distribution, build number management, Fastlane integration, and artifact retention

SKILL.md

10.2 KB, as published. Nobody here has run it

You are in AUTONOMOUS MODE. Do NOT ask questions. Do NOT pause for confirmation. Execute every phase below in sequence, making decisions based on what you find.

============================================================ PHASE 0 — INPUT

$ARGUMENTS may contain:

  • A CI/CD platform: github-actions (default), bitrise, codemagic
  • A specific focus: code-signing, testflight, play-store, testing, artifacts
  • --ios-only or --android-only to limit scope
  • If no arguments, configure a complete pipeline using GitHub Actions for all detected platforms

============================================================ PHASE 1 — PROJECT DETECTION

  1. Detect the mobile framework:

    • pubspec.yaml with flutter SDK -> Flutter (iOS + Android)
    • *.xcodeproj or *.xcworkspace (no Flutter) -> Native iOS
    • build.gradle.kts with android plugin (no Flutter) -> Native Android
    • package.json with react-native -> React Native (iOS + Android)
    • package.json with expo -> Expo (iOS + Android)
  2. Detect existing CI/CD:

    • .github/workflows/ -> GitHub Actions
    • bitrise.yml -> Bitrise
    • codemagic.yaml -> Codemagic
    • .circleci/ -> CircleCI
  3. Detect existing Fastlane:

    • fastlane/Fastfile -> Use existing lanes
    • If absent, generate Fastlane configuration as part of this skill
  4. Detect signing configuration:

    • iOS: Fastlane match, manual profiles, Xcode automatic signing
    • Android: keystore in build.gradle, key.properties, or environment-based

============================================================ PHASE 2 — iOS PIPELINE

Generate .github/workflows/ios.yml:

Triggers: Push to main/develop, PRs to main/develop. Use concurrency groups with cancel-in-progress: true.

Test job (runs on macos-14):

  • Framework-specific setup (Flutter action with cache, or Xcode setup)
  • Static analysis (flutter analyze, SwiftLint)
  • Unit tests with coverage
  • Upload coverage to Codecov/Coveralls

TestFlight job (runs on push to develop):

  • Install Fastlane via Bundler
  • Code signing via Fastlane match (appstore profile, readonly)
  • Required secrets: MATCH_PASSWORD, MATCH_GIT_TOKEN, ASC_KEY_ID, ASC_ISSUER_ID, ASC_KEY_CONTENT
  • Build and upload via fastlane beta
  • Upload IPA as artifact (14-day retention)
  • Upload dSYMs for crash symbolication

App Store job (runs on tag v*.*.*):

  • Same signing setup as TestFlight
  • Build and upload via fastlane release

============================================================ PHASE 3 — ANDROID PIPELINE

Generate .github/workflows/android.yml:

Triggers: Same as iOS. Concurrency groups.

Test job (runs on ubuntu-latest):

  • Java 17 setup with Gradle cache
  • Framework-specific setup (Flutter, React Native, or native)
  • Static analysis (flutter analyze, ./gradlew lint)
  • Unit tests with coverage

Internal Track job (runs on push to develop):

  • Decode keystore from base64 secret
  • Required secrets: KEYSTORE_BASE64, KEYSTORE_PASSWORD, KEY_ALIAS, KEY_PASSWORD, PLAY_STORE_JSON_KEY
  • Build AAB (never APK for Play Store)
  • Upload to internal testing track via Fastlane supply
  • Upload AAB as artifact (14-day retention)
  • Upload mapping files for ProGuard deobfuscation

Production job (runs on tag v*.*.*):

  • Same signing setup
  • Upload to production with staged rollout (start at 10%)

============================================================ PHASE 4 — BUILD NUMBER MANAGEMENT

Configure a build number strategy that guarantees monotonically increasing values:

Recommended: CI run number (${{ github.run_number }}) — simple and monotonic.

Alternative A: Git commit count (git rev-list --count HEAD) — tied to commit history.

Alternative B: Timestamp (date +%Y%m%d%H%M) — works for infrequent builds.

Inject build number per framework:

  • Flutter: flutter build --build-number=$BUILD_NUMBER
  • iOS Native: Fastlane increment_build_number(build_number: ENV["BUILD_NUMBER"])
  • Android Native: Set versionCode from environment variable in gradle

============================================================ PHASE 5 — CODE SIGNING IN CI

iOS Signing:

  • Fastlane match with git-based encrypted certificate storage
  • App Store Connect API key (preferred over password auth in CI)
  • Temporary keychain created and destroyed per job (match handles this)

Android Signing:

  • Keystore stored as base64-encoded GitHub secret
  • Decoded to file before build, deleted after
  • Play Store service account JSON key as secret

Generate a signing setup checklist documenting every secret, where to obtain it, and how to encode it.

============================================================ PHASE 6 — AUTOMATED TESTING

Configure comprehensive test jobs:

Unit tests: Flutter flutter test --coverage, iOS xcodebuild test, Android ./gradlew test

Static analysis: Flutter flutter analyze, iOS SwiftLint, Android ./gradlew lint

Coverage: Upload to Codecov or Coveralls. Set minimum coverage thresholds.

Optional UI tests:

  • iOS: Simulator-based tests on macOS runner
  • Android: Firebase Test Lab integration via Fastlane
  • Flutter: flutter test integration_test/ on simulator/emulator

============================================================ PHASE 7 — ARTIFACT MANAGEMENT

Configure artifact retention:

  • IPA / AAB files: 14-day retention for PR builds, 90-day for releases
  • Test results: always uploaded as artifacts
  • Coverage reports: uploaded to coverage service
  • dSYM files: archived for crash symbolication
  • Mapping files: archived for ProGuard deobfuscation

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After completing deployment/infrastructure changes, validate:

  1. Verify all generated files are syntactically valid (YAML, JSON, HCL, Dockerfile).
  2. Run validation commands if available (terraform validate, docker build --check, kubectl dry-run).
  3. Verify no secrets, credentials, or sensitive values are hardcoded.
  4. If validation fails, diagnose and fix the specific syntax or config error.
  5. Repeat up to 2 iterations.

IF STILL FAILING after 2 iterations:

  • Document what failed and the exact error
  • Include partial output if available

============================================================ OUTPUT

## Mobile CI/CD Pipeline Complete

### Platform: {GitHub Actions / Bitrise / Codemagic}
### Framework: {Flutter / iOS Native / Android Native / React Native}

### Pipeline Overview
| Trigger | iOS Action | Android Action |
|---------|------------|----------------|
| PR | Test + analyze | Test + lint |
| Push to develop | Test + TestFlight | Test + Internal Track |
| Tag v*.*.* | Test + App Store | Test + Production (10%) |

### Required Secrets
| Secret | Platform | How to Obtain |
|--------|----------|---------------|
| MATCH_PASSWORD | iOS | Chosen during match init |
| MATCH_GIT_TOKEN | iOS | GitHub PAT with repo scope |
| ASC_KEY_ID | iOS | App Store Connect > Keys |
| ASC_ISSUER_ID | iOS | App Store Connect > Keys |
| ASC_KEY_CONTENT | iOS | .p8 file contents |
| KEYSTORE_BASE64 | Android | base64 -w0 upload-keystore.jks |
| KEYSTORE_PASSWORD | Android | Chosen during keytool |
| KEY_ALIAS | Android | Chosen during keytool |
| KEY_PASSWORD | Android | Chosen during keytool |
| PLAY_STORE_JSON_KEY | Android | GCP service account JSON |

### Files Created
{list all generated workflow and configuration files}

============================================================ NEXT STEPS

  1. Configure the required secrets in your GitHub repository settings
  2. Run deploy/play-store-publish to set up Fastlane lanes for Play Store
  3. Run deploy/app-store-publish to set up Fastlane lanes for App Store
  4. Run deploy/ota-updates to configure over-the-air update infrastructure

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

  • Look for the project path in ~/.claude/projects/
  • If found, append to skill-telemetry.md in that memory directory

Entry format:

### /mobile-ci-cd — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.

============================================================ DO NOT

  • Do NOT store signing keys, keystores, or API keys in the repository
  • Do NOT use self-hosted runners for code signing without proper secret isolation
  • Do NOT skip test jobs — builds without tests provide false confidence
  • Do NOT build APK instead of AAB for Play Store uploads
  • Do NOT use password-based App Store Connect auth — API keys are more reliable in CI
  • Do NOT hardcode build numbers — they must be dynamic and monotonically increasing
  • Do NOT skip artifact upload — build outputs are needed for debugging and compliance
  • Do NOT use deprecated action versions — pin to latest major versions

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.