vibefast-cli 0.6.2 → 0.7.1

package/2/.cursor/commands/code-review-high.md

@@ -1,190 +0,0 @@
-<task>
-$1
-</task>
-
-<role>
-  You are a senior software engineer, security reviewer, and performance specialist. Review the provided change with a focus on correctness, security, performance, integration, test quality, and long-term maintainability. Be precise, cite file paths and line ranges, and prioritize risks that could impact users, data, uptime, or developer velocity.
-</role>
-
-<objectives>
-- Identify correctness defects, code smells, and anti-patterns.
-- Surface exploitable security issues and data-protection risks.
-- Spot performance/regression risks and complexity hotspots.
-- Check integration points (APIs, events, DB, configs, CI/CD, infra) for compatibility and rollout safety.
-- Assess tests for sufficiency, signal, reliability, and coverage.
-- Recommend minimal, safe, high-leverage improvements and monitoring.
-</objectives>
-
-<severity_rubric>
-
-- BLOCKER: Exploitable security flaw, data loss risk, broken build/deploy, user-impacting crash, irreversible migration risk, leaked secrets.
-- HIGH: Likely prod incident or major regression; authz/auth gaps; significant perf degradation; schema incompatibility.
-- MEDIUM: Correctness edge cases; non-exploitable but risky pattern; moderate perf concerns; flaky tests.
-- LOW: Maintainability, readability, style, minor test gaps; suggestions.
-- NIT: Optional polish.
-  </severity_rubric>
-
-<tasks>
-- Scope & Impact: Map all affected files/modules and why each is implicated. Note transitive and runtime impact (build, deploy, config, data).
-- Root Cause / Risk Analysis: Explain the change intent, risks introduced, and any hidden assumptions or environmental dependencies.
-- Security Review: Use the checklist below; escalate any secret exposure, injection, auth/authz flaws, SSRF/XXE/path traversal, insecure deserialization, command execution, mass assignment, CSRF/XSS, prototype pollution, weak crypto, missing TLS verification, permissive CORS, logging of secrets/PII, dependency vulns, or IaC/container misconfigurations.
-- Performance Review: Identify complexity issues, N+1 queries, unbounded loops, memory churn/leaks, blocking I/O on hot paths, missing indexes, cache misuse, chatty network calls, unnecessary allocations/boxing, and concurrency contention.
-- Integration Review: Validate API schema changes, versioning, backward/forward compatibility, idempotency, retries/timeouts/circuit breakers, feature-flag rollout, DB migrations (order/locking/rollback), message/event contracts, and config drift.
-- Testing Review: Evaluate unit/integration/e2e tests, coverage, negative/property-based cases, concurrency/time-dependent tests, fixture health, determinism, and flakiness risk. Propose a targeted test plan.
-- Observability & Operations: Check log levels, PII in logs, correlation/trace IDs, metrics and alerts, runbooks. Recommend what to monitor post-merge.
-- Documentation & DX: Flag missing or outdated README/CHANGELOG/ADRs/API docs/config comments/schema diagrams. Note onboarding and maintenance friction.
-- Minimal, Safe Fix: Propose the smallest viable change to eliminate blockers/high risks. Include tests and rollout/rollback steps.
-</tasks>
-
-<detailed_checklist>
-<category name="Correctness & Code Smells">
-
-- Duplicate code / long methods / large classes / deep nesting.
-- Leaky abstractions, tight coupling, poor cohesion, improper layering.
-- Dead code, unused variables/imports, TODOs that should be addressed now.
-- Non-idempotent operations where idempotency is required.
-- Edge cases: null/empty/NaN/overflow/encoding/timezone/locale.
-- Concurrency: shared state, race conditions, improper locking, async misuse.
-  </category>
-
-  <category name="Security">
-
-- Secrets in code/logs/env/examples; credential handling, key rotation, KMS/secret manager usage.
-- Input validation & output encoding; SQL/NoSQL/LDAP/OS injection; XSS (reflected/stored/DOM); CSRF.
-- AuthN/AuthZ: broken access control, least privilege, multi-tenant boundaries, insecure direct object references.
-- SSRF/XXE/path traversal/file upload validation; sandboxing for untrusted inputs.
-- Crypto: algorithms, modes, IVs, nonces, randomness, key sizes, cert pinning/TLS verification.
-- CORS/security headers (CSP/HSTS/X-Frame-Options/SameSite), cookie flags.
-- Dependency & supply chain: pinned versions, known CVEs, pre/post-install scripts, integrity checks.
-- IaC/Containers: public buckets, open security groups (0.0.0.0/0), missing encryption, root containers, mutable latest tags.
-- Data protection & privacy: PII/PHI handling, minimization, retention, encryption at rest/in transit.
-  </category>
-
-  <category name="Performance">
-
-- Time/space complexity, hot-path allocations, unnecessary synchronization.
-- N+1 queries, missing DB indexes, inefficient joins, full scans, pagination vs. streaming.
-- Caching: invalidation, eviction, key design, stampedes.
-- Network patterns: chattiness, batching, compression, timeouts, backoff.
-- Client-side perf (if UI): bundle size/regressions, critical path, images/fonts.
-  </category>
-
-  <category name="Integration & Rollout Safety">
-
-- Backward/forward compatibility; versioned contracts; consumer-producer alignment.
-- DB migrations: zero-downtime (expand/migrate/contract), locks, data backfills, rollback plan.
-- Feature flags: default off, kill switch, gradual rollout, owner/expiry.
-- Resilience: retries with jitter, timeouts, circuit breakers, idempotency keys.
-- Config changes: validation, defaults, environment parity, secrets not in plain text.
-- CI/CD: reproducibility, cache safety, test gates, artifact signing.
-  </category>
-
-  <category name="Testing & Quality Signals">
-
-- Tests exist for new behavior and regressions; meaningful assertions.
-- Coverage on critical branches/edge cases; mutation score (if available).
-- Isolation: minimal mocking vs. over-mocking; flaky patterns (sleep-based timing, order reliance).
-- Property-based/fuzz tests for parsers/validators/serializers.
-- Load/soak tests where perf risk exists; snapshot tests stability (if UI).
-  </category>
-
-  <category name="Docs, Observability, Accessibility, i18n">
-
-- README/CHANGELOG/ADR/API docs updated; code comments for non-obvious logic.
-- Logs/metrics/traces with actionable context; PII redaction; alert thresholds.
-- Accessibility (if UI): semantics, focus order, labels, contrast, keyboard nav, ARIA use.
-- i18n/l10n: hard-coded strings, pluralization, date/time/number formats.
-  </category>
-  </detailed_checklist>
-
-  <output_requirements>
-  <instructions>
-
-- Produce a concise but comprehensive report.
-- Group findings by category and severity.
-- Reference exact file paths and line ranges (e.g., src/foo/bar.py:120–147).
-- Include brief code excerpts only as necessary (≤20 lines per finding).
-- Prefer specific, minimal fixes and tests that maximize risk reduction.
-- If information is missing, state the assumption and its impact.
-  </instructions>
-  </output_requirements>
-
-  <report_skeleton>
-
-- Summary:
-  - What changed: <concise overview>
-  - Top risks: <1-3 bullets>
-  - Approval: <approve|comment|request_changes|blocker>
-
-- Affected files:
-  - <path> — <reason> (<added|modified|deleted>)
-
-- Root cause & assumptions:
-  - <analysis>
-  - Assumptions: <items>
-
-- Findings (repeat per finding):
-  - [<severity>] [<category>] <short title>
-    - Where: <file:line-range>
-    - Evidence: <brief snippet_trace>
-    - Impact: <what breaks_who is affected>
-    - Standards: <CWE/OWASP/Policy refs>
-    - Repro: <steps>
-    - Recommendation: <minimal fix>
-    - Tests: <tests to add_update>
-
-- Performance:
-  - Hotspots: <items>
-  - Complexity notes: <items>
-  - Bench/Monitoring plan: <how to measure & watch>
-
-- Integration:
-  - API/contracts: <compat/versioning/idempotency>
-  - DB migrations: <expand-migrate-contract, locks, rollback>
-  - Feature flags & rollout: <plan/kill switch_owner>
-  - Resilience: <timeouts/retries/circuits>
-  - Rollback plan: <how to revert safely>
-
-- Testing:
-  - Coverage: <statements_branches_critical_paths>
-  - Gaps: <cases>
-  - Flakiness risks: <items>
-  - Targeted test plan: <Given_When_Then bullets>
-
-- Docs & Observability:
-  - Docs to update/create: <paths/sections>
-  - Logs/Metrics/Traces/Alerts: <plan>
-  - Runbook: <updates>
-
-- Open questions:
-  - <items>
-
-- Final recommendation:
-  - Decision: <approve|comment|request_changes|blocker>
-  - Must-fix before merge: <items>
-  - Nice-to-have post-merge: <items>
-  - Confidence: <low|medium|high>
-    </report_skeleton>
-
-<process_notes>
-
-- Prioritize BLOCKER/HIGH issues. If any are found, set approval to “blocker” or “request_changes”.
-- Favor minimal, safe changes and targeted tests over broad refactors (unless safety demands it).
-- If diff is very large, focus on high-risk/new code paths, public interfaces, security-critical modules, and hot paths.
-- Reference concrete files/lines. Keep code excerpts minimal (≤20 lines). Do not rewrite large code blocks.
-- If required inputs are missing (e.g., DB migration script or API schema), flag as a risk and propose what is needed.
-  </process_notes>
-
-<constraints>
-- DO NOT write or generate full code implementations in this review. Provide patch outlines, pseudocode, or stepwise instructions only.
-- Maintain confidentiality: if a secret or sensitive data appears, describe it without reproducing it verbatim.
-</constraints>
-
-<success_criteria>
-
-- Findings are specific, actionable, and ordered by severity and blast radius.
-- Every high-risk change has a minimal fix and a concrete test/monitoring plan.
-- Output follows the provided report skeleton (markdown text only).
-  </success_criteria>
-
-<reminder>DON'T CODE YET.</reminder>

package/2/.cursorignore

@@ -1,3 +0,0 @@
-!.env
-!.env.local
-!.env.production

package/2/.github/ISSUE_TEMPLATE.md

@@ -1,13 +0,0 @@
-# Summary:
-
-## Steps to reproduce:
-
-## Expected behavior:
-
-## Additional notes:
-
-#### Tasks
-
-- [ ] Task 1
-- [ ] Task 2
-- [ ] Task 3

package/2/.github/PULL_REQUEST_TEMPLATE.md

@@ -1,23 +0,0 @@
-## What does this do?
-
-<!---
-_Describe what your changes **do**; did you add a $COOL_FEATURE? Write about it here._
--->
-
-## Why did you do this?
-
-<!---
-_**Why** did you make these changes? This is your opportunity to provide the rationale that drove the design of your solution._
--->
-
-## Who/what does this impact?
-
-<!---
-_Does your code affect something downstream? Are there side effects people should know about? Tag any developers that should be kept abreast of this change._
--->
-
-## How did you test this?
-
-<!---
-_How did you test your change? Document it here._
--->

package/2/.github/actions/eas-build/action.yml

@@ -1,85 +0,0 @@
-# 🔗 Links:
-# Source file: https://github.com/obytes/react-native-template-obytes/blob/master/.github/actions/eas-build/action.yml
-# EAS Build docs: https://docs.expo.dev/eas-update/github-actions/
-
-# ✍️ Description:
-# This is a composite action, which means it can be used in other actions.
-# This action is used to trigger an EAS Build for a specific environment (local, staging, production).
-# This action accepts those inputs:
-#        `APP_ENV`, which is used to generate an APK for a specific environment (local, staging, production). We use staging by default.
-#        `AUTO_SUBMIT`, false by default, set to true if you want to automatically submit your build to stores.
-#        `EXPO_TOKEN`, required, access token for your Expo account. https://expo.dev/settings/access-tokens
-#        `VERSION`, required, version of the app to build. used as the build message.
-#        `ANDROID`, true by default, set to true if you don't want to trigger build for Android.
-#        `IOS`, false by default, set to true if you  want to trigger build for IOS.
-
-# Before triggering the build, we run a pre-build script to generate the necessary native folders based on the APP_ENV.
-# Based on the ANDROID and IOS inputs, we trigger the build for the corresponding platform with the corresponding flags.
-
-# 👀 Example usage:
-#      - name: ⏱️ EAS Build
-#        uses: ./.github/actions/eas-build
-#        with:
-#          APP_ENV: staging
-#          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
-#          VERSION: ${{ github.event.release.tag_name }}
-#          IOS: false
-
-name: 'Setup EAS Build + Trigger Build'
-description: 'Setup EAS Build + Trigger Build'
-inputs:
-  APP_ENV:
-    description: 'APP_ENV (one of): local, staging, production'
-    required: true
-    default: 'staging'
-  AUTO_SUBMIT: ## TODO: we need to handle this too
-    description: 'AUTO_SUBMIT (one of): true, false'
-    required: true
-    default: 'false'
-  ANDROID:
-    description: 'run for ANDROID (one of): true, false'
-    required: true
-    default: 'true'
-  VERSION:
-    description: 'VERSION'
-    required: true
-    default: '0.0.0'
-  IOS:
-    description: 'run for IOS (one of): true, false'
-    required: true
-    default: 'false'
-  EXPO_TOKEN:
-    description: 'EXPO_TOKEN'
-    required: true
-    default: 'false'
-
-runs:
-  using: 'composite'
-  steps:
-    - name: 💯 Check for EXPO_TOKEN
-      run: |
-        if [ -z "${{ inputs.EXPO_TOKEN }}" ]; then
-          echo "You must provide an EXPO_TOKEN secret linked to this project's Expo account in this repo's secrets. Learn more: https://docs.expo.dev/eas-update/github-actions"
-          exit 1
-        fi
-      shell: bash
-
-    - name: 📦 Setup Expo and EAS
-      uses: expo/expo-github-action@v8
-      with:
-        eas-version: latest
-        token: ${{ inputs.EXPO_TOKEN }}
-
-    - name: ⚙️ Run Prebuild
-      run: pnpm prebuild:${{ inputs.APP_ENV }}
-      shell: bash
-
-    - name: 📱 Run Android Build
-      if: ${{ inputs.ANDROID == 'true' }}
-      run: pnpm build:${{ inputs.APP_ENV }}:android --non-interactive  --no-wait --message "Build  ${{ inputs.APP_ENV }} ${{ inputs.VERSION }}"
-      shell: bash
-
-    - name: 📱 Run IOS Build
-      if: ${{ inputs.IOS == 'true' }}
-      run: pnpm build:${{ inputs.APP_ENV }}:ios --non-interactive  --no-wait --message "Build ${{ inputs.APP_ENV }} ${{ inputs.VERSION }}"
-      shell: bash

package/2/.github/actions/setup-jdk-generate-apk/action.yml

@@ -1,48 +0,0 @@
-# 🔗 Links:
-# Source file: https://github.com/obytes/react-native-template-obytes/blob/master/.github/actions/setup-jdk-generate-apk/action.yml
-# Composite actions docs: https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
-
-# ✍️ Description:
-# This is a composite action, which means it can be used in other actions.
-# This action is used to set up the JDK environment and generate an Android APK for testing.
-# This action accepts one input: `APP_ENV`, which is used to generate an APK for a specific environment (local, staging, production). We use staging by default.
-# Before generating the APK, we run a pre-build script to generate the necessary native folders based on the APP_ENV.
-# On success, the APK is generated at `./android/app/build/outputs/apk/release/app-release.apk`.
-
-# 👀 Example usage:
-#       - name : 📦 Set Up JDK + Generate Test APK
-#         uses: ./.github/actions/setup-jdk-generate-apk
-#         with:
-#           APP_ENV: 'staging'
-
-name: 'Setup  JDK + GRADLE + Generate APK'
-description: 'Setup  JDK + GRADLE + Generate APK'
-inputs:
-  APP_ENV:
-    description: 'APP_ENV (one of): local, staging, production'
-    required: true
-    default: 'staging'
-
-runs:
-  using: 'composite'
-  steps:
-    - name: Set Up JDK
-      uses: actions/setup-java@v3
-      with:
-        distribution: 'zulu' # See 'Supported distributions' for available options
-        java-version: '17'
-    - name: Setup Gradle
-      uses: gradle/gradle-build-action@v2
-
-    - name: Generate Test APK
-      run: |
-        pnpm prebuild:${{ inputs.APP_ENV }}
-        cd  android
-        chmod +x ./gradlew
-        ./gradlew assembleRelease --no-daemon
-        cd ..
-      shell: bash
-      env:
-        EXPO_NO_DOTENV: '1'
-        APP_ENV: ${{ inputs.APP_ENV }}
-        CI: 'true'

package/2/.github/actions/setup-node-pnpm-install/action.yml

@@ -1,29 +0,0 @@
-# 🔗 Links:
-# Source file: https://github.com/obytes/react-native-template-obytes/blob/master/.github/actions/setup-node-pnpm-install/action.yml
-# Composite actions docs: https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
-
-# ✍️ Description:
-# This is a composite action, which means it can be used in other actions.
-# It is used in almost all workflows to set up the environment and install dependencies.
-# Updating  the package manager or Node version here will be reflected in all workflows.
-
-# 👀 Example usage:
-#       - name : 📦 Setup Node + PNPM + install deps
-#         uses: ./.github/actions/setup-node-pnpm-install
-
-name: 'Setup  Node + PNPM + Install Dependencies'
-description: 'Setup  Node + PNPM + Install Dependencies'
-runs:
-  using: 'composite'
-  steps:
-    - uses: pnpm/action-setup@v4
-      with:
-        run_install: false
-    - uses: actions/setup-node@v4
-      with:
-        node-version: 20
-        cache: 'pnpm'
-
-    - name: 📦 Install Project Dependencies
-      run: pnpm install --frozen-lockfile
-      shell: bash

package/2/.github/scripts/expo-doctor.sh

@@ -1,26 +0,0 @@
-#!/bin/bash
-
-# Run expo-doctor and capture output and exit code
-output=$(npx expo-doctor@latest 2>&1)
-exit_code=$?
-
-# Output file location
-output_file=".expo/expo-doctor.md"
-{
-  # Add summary based on exit code
-  if [ $exit_code -eq 0 ]; then
-    echo "✅ **Good news!** We ran Expo Doctor for this PR and everything looks good, Great job!" > "$output_file"
-  else
-    echo "❌ **Action Required:**  We ran Expo Doctor for this PR and found some issues that need to be addressed. Please review the complete report below 👇" > "$output_file"
-    echo >> "$output_file"  # Add blank line
-    echo "\`\`\`shell" >> "$output_file"
-    echo "$output" >> "$output_file"
-    echo "\`\`\`" >> "$output_file"
-  fi
-}
-
-# Show original output in terminal
-echo "$output"
-
-# Return the original exit code
-exit $exit_code

package/2/.github/workflows/compress-images.yml

@@ -1,48 +0,0 @@
-# 🔗 Links:
-# Source file: https://github.com/obytes/react-native-template-obytes/blob/master/.github/workflows/compress-images.yml
-
-# ✍️ Description:
-# This workflow is used to compress images in the repo.
-# This workflow will trigger on a push to the "master" or "main" branch and only run when a new image is added or updated.
-# If it's the case, it will compress those images and create a pull request with the compressed images.
-
-# 🚨 GITHUB SECRETS REQUIRED: None
-
-name: Compress images
-on:
-  push:
-    branches:
-      - master
-      - main
-    paths:
-      - '**.jpg'
-      - '**.jpeg'
-      - '**.png'
-      - '**.webp'
-  workflow_dispatch:
-
-jobs:
-  build:
-    name: calibreapp/image-actions
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout Branch
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-      - name: Compress Images
-        id: calibre
-        uses: calibreapp/image-actions@main
-        with:
-          githubToken: ${{ secrets.GITHUB_TOKEN }}
-          compressOnly: true
-          ignorePaths: 'node_modules/**,ios/**,android/**'
-
-      - name: Create Pull Request
-        if: steps.calibre.outputs.markdown != ''
-        uses: peter-evans/create-pull-request@v3
-        with:
-          title: Auto Compress Images
-          branch-suffix: timestamp
-          commit-message: Compress Images
-          body: ${{ steps.calibre.outputs.markdown }}

package/2/.github/workflows/e2e-android-eas-build.yml

@@ -1,111 +0,0 @@
-# 🔗 Links:
-# Source file: https://github.com/obytes/react-native-template-obytes/blob/master/.github/workflows/e2e-android-eas-build.yml
-# End-to-end testing: https://starter.obytes.com/testing/end-to-end-testing/
-
-# ✍️ Description:
-# This workflow is used to run end-to-end tests for EAS build on Android.
-# It uses Maestro Cloud to run tests on Android emulator.
-# It downloads the APK from EAS build and triggers the tests on Maestro Cloud with the downloaded APK.
-
-# 🚨 GITHUB SECRETS REQUIRED:
-# MAESTRO_CLOUD_API_KEY: API key for Maestro Cloud. You can get it from https://cloud.mobile.dev/ci-integration/github-actions#add-your-api-key-secret
-
-name: E2E Tests EAS Build Android (Maestro + Github Action)
-
-on:
-  workflow_dispatch:
-    inputs:
-      apk-url:
-        type: string
-        description: 'EAS APK URL'
-        required: true
-        default: ''
-
-jobs:
-  download-eas-apk:
-    if: github.event_name != 'pull_request'  && github.event.inputs.apk-url != ''
-    name: Download Test APK From EAS Url (wget)
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: 📦 Download EAS APK
-        run: wget ${{ github.event.inputs.apk-url }} -O ./app-release.apk
-
-      - name: Upload Test APK
-        uses: actions/upload-artifact@v3
-        with:
-          name: test-apk
-          path: ./app-release.apk
-
-  test-android:
-    name: E2E Tests EAS Build Android (Maestro + Github Action)
-    needs: download-eas-apk
-    runs-on: macOS-latest
-
-    steps:
-      - name: 📦 Checkout project repo
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: 📦 Install Maestro
-        run: npm run install-maestro ## We use npm because we don't need to install deps again
-
-      - name: Download Test APK
-        uses: actions/download-artifact@v3
-        with:
-          name: test-apk
-          path: ${{ github.workspace }}
-
-      - name: Gradle cache
-        uses: gradle/gradle-build-action@v2
-
-      - name: AVD cache
-        uses: actions/cache@v3
-        id: avd-cache
-        with:
-          path: |
-            ~/.android/avd/*
-            ~/.android/adb*
-          key: avd-cache
-
-      - name: create AVD and generate snapshot for caching
-        if: steps.avd-cache.outputs.cache-hit != 'true'
-        uses: reactivecircus/android-emulator-runner@v2
-        with:
-          api-level: 29
-          force-avd-creation: false
-          emulator-options: -no-window -gpu swiftshader_indirect -noaudio -no-boot-anim -camera-back none
-          disable-animations: false
-          cores: 2
-          ram-size: 4096M
-          profile: Nexus 6
-          script: echo "Generated AVD snapshot for caching."
-
-      - name: Run tests with Maestro
-        uses: reactivecircus/android-emulator-runner@v2
-        with:
-          api-level: 29
-          force-avd-creation: false
-          emulator-options: -no-snapshot-save -no-window -gpu swiftshader_indirect -noaudio -no-boot-anim -camera-back none
-          disable-animations: false
-          cores: 2
-          ram-size: 4096M
-          profile: Nexus 6
-          script: |
-            adb install "${{ github.workspace }}/app-release.apk"
-            $HOME/.maestro/bin/maestro test .maestro/ --env=APP_ID=com.vibefast.staging  --format junit
-
-      - name: Upload artifacts
-        if: always()
-        uses: actions/upload-artifact@v3
-        with:
-          name: e2e-test-logs
-          path: ~/.maestro/tests/**/*
-
-      - name: Store tests result
-        uses: actions/upload-artifact@v3
-        with:
-          name: e2e_android_report
-          path: |
-            report.xml

package/2/.github/workflows/e2e-android-maestro.yml

@@ -1,52 +0,0 @@
-# 🔗 Links:
-# Source file: https://github.com/obytes/react-native-template-obytes/blob/master/.github/workflows/e2e-android.yml
-# End-to-end testing: https://starter.obytes.com/testing/end-to-end-testing/
-
-# ✍️ Description:
-# This workflow is used to run end-to-end tests on Android using Maestro Cloud.
-# As a first step, it will generate a test APK using the Gradle build and  then trigger  Maestro Cloud to run the tests on the generated APK.
-# This workflow will be triggered on pull requests (PRs) with the label "android-test-maestro-cloud" or can be manually triggered from the Actions tab.
-
-# 🚨 GITHUB SECRETS REQUIRED:
-# MAESTRO_CLOUD_API_KEY: API key for Maestro Cloud. You can get it from https://cloud.mobile.dev/ci-integration/github-actions#add-your-api-key-secret
-
-name: E2E Tests Android (Maestro Cloud)
-
-on:
-  workflow_dispatch:
-  pull_request:
-    branches: [main, master]
-
-jobs:
-  generate-and-test-apk:
-    if: github.event_name != 'pull_request' || ( github.event_name == 'pull_request' && contains(github.event.pull_request.labels.*.name, 'android-test-maestro-cloud'))
-    name: Generate and Test Test APK (Maestro Cloud)
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: 📦 Checkout project repo
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: 📦 Setup Node + PNPM + install deps
-        uses: ./.github/actions/setup-node-pnpm-install
-
-      - name: 📦 Set Up JDK + Generate Test APK
-        uses: ./.github/actions/setup-jdk-generate-apk
-        with:
-          APP_ENV: staging
-
-      - name: Upload Test APK
-        uses: actions/upload-artifact@v3
-        with:
-          name: test-apk
-          path: ./android/app/build/outputs/apk/release/app-release.apk
-
-      - name: 📱 Run E2E Tests with Maestro Cloud
-        uses: mobile-dev-inc/action-maestro-cloud@v1.4.1
-        with:
-          api-key: ${{ secrets.MAESTRO_CLOUD_API_KEY }}
-          app-file: ./android/app/build/outputs/apk/release/app-release.apk
-          env: |
-            APP_ID=com.vibefast.staging