fix: Pin release candidate to Source Fastlane track to prevent stale promotions - #7352
fix: Pin release candidate to Source Fastlane track to prevent stale promotions#7352AmyLGalles wants to merge 2 commits into
Conversation
Promoting internal -> production intermittently fails with "Cannot find release with version code" because Google's Play API only returns the latest release per track, and continuous internal builds supersede the candidate before someone runs the promotion workflow. There's an existing manual workaround (a "Source Fastlane" holding track) but nothing keeps it fresh, so it goes stale too. Pin the just-uploaded internal build onto Source Fastlane in the same CI run, immediately after upload, before any later build can supersede it. Reuses the existing promoteToProduction lane; adds an optional serviceCredentialsFile override needed for the Authenticator job, which doesn't have play_creds.json on disk.
Code review caught two real gaps in the previous commit: - Pinning on every main push made Source Fastlane just as volatile as internal, since builds land on main continuously while a release candidate is cut on a dedicated release/<version>-rcN branch and can sit for a while before someone promotes it. Gate the pin step to release/* branches so it only refreshes when a real RC is cut. - promoteToProduction's serviceCredentialsFile override had no package-name fallback like the sibling getLivePlayStoreVersion lane, so the real bitwarden/deploy caller (which never passes it) still resolved play_creds.json for the Authenticator package.
🤖 Bitwarden Claude Code ReviewOverall Assessment: APPROVE Reviewed a CI/release-tooling change that adds a "Pin release to Source Fastlane track" step to both No findings at or above the reporting threshold. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7352 +/- ##
=======================================
Coverage 86.20% 86.20%
=======================================
Files 901 901
Lines 66257 66257
Branches 10170 10170
=======================================
Hits 57118 57118
Misses 5561 5561
Partials 3578 3578
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
🎟️ Tracking
No Jira ticket — this comes from investigating recurring "Cannot find release with version code" failures observed in bitwarden/deploy's Android production-promotion workflow runs on 2026-09-03 (Authenticator) and 2026-08-20 (Password Manager).
📔 Objective
Promoting a build from Play Store
internal→productionintermittently fails because Google's Play API only returns the latest release per track, and continuousmain-branch builds supersede the release candidate before someone runs the promotion workflow. There's an existing manual workaround (a second track namedSource Fastlane) but nothing keeps it fresh, so it goes stale too.This adds a new CI step — gated to
release/*branch builds only, not everymainpush — that pins the just-uploadedinternalrelease ontoSource Fastlaneimmediately after upload, before any later build can supersede it. Reuses the existingpromoteToProductionfastlane lane.Also fixes a credentials-resolution gap:
promoteToProduction's newserviceCredentialsFileoverride now falls back to the correct Authenticator credentials file by package name (matching the pattern already used bygetLivePlayStoreVersion), so the realbitwarden/deploycaller — which never passes this override — authenticates correctly forcom.bitwarden.authenticatorinstead of silently using the Password Manager's credentials.Reviewed locally via
/bitwarden-code-review:code-review-local. Addressed the important finding (pin was originally unscoped to release branches, which would have made it just as volatile asinternal) and the suggested finding (credentials fallback) before opening this PR.📸 Screenshots
N/A — CI workflow / Fastfile change only.