fix(mobile): let deploy's build lookups wait for a build already in progress

Merged
SA
2mo ago
+2-0

Seen on the first afternoon of the deploy lane: three production builds (35, 36, 37) with the identical fingerprint 3658c7e2…, each uploaded to App Store Connect, because #7408 and #7428 merged while the previous build was still running and the get-build lookup only matches finished builds.

wait_for_in_progress: true on both lookups in deploy.yml, matching pr-preview.yml. A merge that lands mid-build now waits for that build and skips its own; the run that started the build is the one that uploads it.

Validated with eas workflow:validate.

Summary by cubic

Fixes duplicate production and internal builds in the mobile deploy lane when a merge lands while a build with the same fingerprint is already running. The lookups now wait for in-progress builds, matching the pull-request lane, so a second merge reuses the running build instead of starting and uploading another.

  • Both build_internal and build_production lookups set wait_for_in_progress: true.
  • The run that starts a build is the one that uploads it.

Summary by CodeRabbit

  • Bug Fixes
    • Mobile builds now wait for an in-progress matching build instead of failing when one is already running.