-
Notifications
You must be signed in to change notification settings - Fork 193
chore: fix mobile auto deploy v2.6.9 rd2 #1225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
) * chore: bump iOS build number to 179 * fix: use PR source commit for deployment to get correct version.json When deploying from a PR merge (e.g., dev → staging), now uses the source branch's commit instead of always checking out staging. This ensures version.json has the correct bumped build number from the previous deployment's PR back to dev, preventing 'build number already exists' errors. * downgrade to match store * fix: use merge_commit_sha instead of head.sha for deployments Use github.event.pull_request.merge_commit_sha instead of head.sha to ensure we deploy exactly what landed on staging after the merge, not just the source branch state. This correctly handles: - Conflict resolutions made during merge - Any staging-only changes - The actual state of staging post-merge The merge commit still includes the updated version.json from the source branch (e.g., dev), so build numbers remain correct while ensuring we deploy and tag the true staging state. Co-authored-by: CodeRabbit <[email protected]> --------- Co-authored-by: CodeRabbit <[email protected]>
WalkthroughUpdates the mobile deployment GitHub Actions workflow to use the PR merge commit SHA as the checkout ref during PR-triggered runs, with a fallback to staging. Adds PR-context logging and preserves original HEAD vs origin/staging comparison for non-PR runs across iOS/Android build, release-tagging, and version update steps. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Dev as Developer
participant GH as GitHub Actions
participant Repo as Repo (staging/PR)
participant iOS as iOS Build
participant Droid as Android Build
participant Ver as Version Update
participant Tag as Release Tagging
Dev->>GH: Trigger workflow (PR or non-PR)
alt PR-triggered
GH->>Repo: Determine ref = PR.merge_commit_sha
Note right of GH: If merge_commit_sha missing, fallback to 'staging'
GH->>GH: Log PR number/title + merge-commit context
else Non-PR
GH->>Repo: Determine ref = 'staging'
GH->>GH: Compare HEAD vs origin/staging and warn if mismatch
end
rect rgb(240,248,255)
GH->>Repo: actions/checkout@ref (resolved above)
GH->>iOS: Build iOS with resolved ref
GH->>Droid: Build Android with resolved ref
end
opt Versioning path
GH->>Ver: Update version.json with resolved ref context
end
opt Release path
GH->>Tag: Create/annotate release tag using resolved ref
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (1).github/workflows/**/*.{yml,yaml}📄 CodeRabbit inference engine (AGENTS.md)
Files:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…224)
chore: bump iOS build number to 179
fix: use PR source commit for deployment to get correct version.json
When deploying from a PR merge (e.g., dev → staging), now uses the source branch's commit instead of always checking out staging. This ensures version.json has the correct bumped build number from the previous deployment's PR back to dev, preventing 'build number already exists' errors.
downgrade to match store
fix: use merge_commit_sha instead of head.sha for deployments
Use github.event.pull_request.merge_commit_sha instead of head.sha to ensure we deploy exactly what landed on staging after the merge, not just the source branch state. This correctly handles:
The merge commit still includes the updated version.json from the source branch (e.g., dev), so build numbers remain correct while ensuring we deploy and tag the true staging state.
Summary by CodeRabbit