SDK-531 Fix iOS SDK Release workflow

[joaodordio]

🔹 Jira Ticket(s)

• SDK-531

✏️ Description

Root cause
The workflow has failed at the same step every release since March. The COCOAPODS_TRUNK_TOKEN secret is invalid (Authentication token is invalid or unverified). Trunk confirms the last successful push was 6.6.7 on Feb 13. Everything 6.7.x is missing from CocoaPods. The "tag already exists" errors on retries are downstream noise from the same root failure.

Why we missed it
Tag and GitHub release happen before the trunk push, so SPM consumers always got the release. The success-only Slack notification meant mid-pipeline failures were silent.

Actions in flight
• Re-register the trunk token against a service account, update the GitHub secret
• Manually push 6.7.3 to CocoaPods today (ships the cocoapods crash fix)
• Workflow changes:
• Idempotent create_git_tag, create_release, pod_trunk_push lanes
• New verify cocoapods publication gate, fails the run if the version isn't live
• if: failure() Slack alert so future breaks ping us immediately

Drop Gemfile.lock

Stops pinning the Ruby release tooling so each run picks up the latest cocoapods and fastlane. The lock file was the reason we drifted to cocoapods 1.14.2 and fastlane 2.228.0, several months stale, with nobody actively bumping it.

Changes

• Delete Gemfile.lock, add it to .gitignore.
• Workflow now runs bundle install instead of gem install cocoapods, so cocoapods comes from the Gemfile and matches whatever fastlane uses. No more mixed versions across steps.
• bundler-cache: false in ruby/setup-ruby since the cache only helps when there's a lock.

Trade-off

Each release run does a fresh bundle install (~30 to 60s slower) and loses byte-for-byte reproducibility. Acceptable for a monthly release job and gives us up-to-date tooling for free. If an upstream regression ever breaks a release, we pin via Gemfile (gem "fastlane", "= x.y.z") rather than restoring the lock.

Verifying

First release after merge will pull whatever's latest on rubygems. The idempotency changes in this same PR make the run safely re-runnable, so worst case is a one-line pin in Gemfile.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.15%. Comparing base (b8d25f2) to head (a46e042).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1078      +/-   ##
==========================================
+ Coverage   72.14%   72.15%   +0.01%     
==========================================
  Files         114      114              
  Lines        9538     9538              
==========================================
+ Hits         6881     6882       +1     
+ Misses       2657     2656       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sumeruchat]

Approving. The idempotent lanes plus the post-push trunk verification close the silent CocoaPods failure that has dropped every 6.7.x release since February, and tracing it to the invalid COCOAPODS_TRUNK_TOKEN with an if: failure() Slack alert fixes the root cause rather than papering over it.

Two non-blocking nits:

1. The verify step (ios-sdk-release.yml:62) has no retry/backoff. A transient trunk API blip could fail an otherwise-good release. It is a false-negative only, so optional, but a short retry would avoid a needless release-day failure.

2. Dropping Gemfile.lock with unconstrained cocoapods/fastlane means each release pulls the latest from rubygems. Fine if that is intentional, but a ~> ceiling or a periodically-refreshed lock would keep an upstream regression from breaking a release on release day.

Good call documenting that the tag and GitHub release run before the pod push. That ordering is exactly why SPM kept working while CocoaPods silently fell behind, and pinning the last good push to 6.6.7 made the root cause unambiguous.