[gha] Merge setup, build, and deploy into single job #3303
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: -884 B (0%) Total Size: 53.3 MB
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3303 +/- ##
=======================================
Coverage 49.61% 49.61%
=======================================
Files 671 671
Lines 27979 27979
Branches 5788 5788
=======================================
Hits 13878 13878
Misses 12911 12911
Partials 1190 1190 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Merged the three separate jobs (setup, build-workers, deploy) into a single build-and-deploy job with conditional steps: - Setup: Check if tarballs exist in GCS (when environment specified) - Build: Execute EAS workflow if needed (empty env or missing tarballs) - Upload: Upload tarballs to GCS under SHA hash - Deploy: Copy tarballs to environment-specific names (when env specified) This simplification reduces job coordination complexity while maintaining the same functionality and conditional execution logic.
When deploying from a custom branch with an environment specified, always rebuild the worker tarballs instead of checking if they already exist. This ensures testing actual branch changes rather than potentially stale tarballs from main. Only skip builds when deploying from main with existing cached tarballs, which is safe since main is the source of truth.
With the assumption that main branch always specifies an environment: - environment=='' only happens on PR builds - Simplified all conditions to avoid redundant checks - Build condition: not main OR (main but no cache) - Upload condition: has environment AND (not main OR no cache) The logic is now much easier to read and maintain while preserving all the same behavior.
Simplified caching logic to always check if tarballs exist for the current SHA, regardless of which branch we're on. Since tarballs are stored by SHA, if they exist, the code is identical and we don't need to rebuild. This removes branch-specific logic and makes the workflow simpler: - Check: Always check cache when deploying - Build: Build if PR testing or cache miss - Upload: Upload when deploying if we built - Deploy: Deploy when environment specified
sjchmiela
force-pushed
the
claude/consolidate-ci-jobs-WvWYO
branch
from
9d361c5 to
f331356
Compare
Pass upload_artifact input to EAS workflow based on whether GHA will upload tarballs to GCS. This avoids unnecessary artifact uploads for PR builds where we build for testing but don't upload results. - Set SHOULD_UPLOAD_ARTIFACT = environment set AND no cache - Pass to EAS workflow via --input upload_artifact - Skip artifact URL extraction when upload was disabled This saves time and storage by only uploading artifacts when needed.
Split the EAS workflow into two jobs to ensure proper architecture: - build_android_worker: Runs on ubuntu-medium (Linux x86_64) - build_ios_worker: Runs on macos-medium (macOS ARM64) This ensures Android tarballs are built on Linux x86_64 architecture matching the GCP deployment VMs, avoiding potential native dependency issues from cross-platform builds. Both jobs respect the upload_artifact input to skip uploads when not needed (e.g., PR builds).
|
⏩ The changelog entry check has been skipped since the "no changelog" label is present. |
sjchmiela
changed the title
AbbanMustafa
approved these changes
Jan 12, 2026
| if: github.ref == 'refs/heads/main' || inputs.environment != '' | ||
| # Upload when deploying if we built something new | ||
| # Don't upload PR builds (no environment) or when using cached tarballs | ||
| if: inputs.environment != '' && steps.check_worker_exists.outputs.worker_exists == 'false' |
Contributor
There was a problem hiding this comment.
If we do want to deploy from our branch to staging lets say we will just need to specify the environment correct? Same as before
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why
The build-and-deploy-worker workflow had three separate jobs (setup, build-workers, deploy) with complex inter-job dependencies and redundant conditional logic. I think if we put it all in one job it should make stuff faster.
How
Consolidated all three jobs into a single
build-and-deployjob with conditional steps:Key simplifications:
environment == ''only occurs on PR buildsI also added back building Linux tarball on Linux not to mix CPU architectures accidentally.
Test Plan
Build on PR. Deployment from a branch.