[nan-li]

Description

One Line Summary

Retry CocoaPods publishing in publish-release.yml until CocoaPods confirms the version is published.

Details

Motivation

pod trunk push can fail with "Calling the GitHub commit API timed out" whether or not CocoaPods published the version. Releasing 5.8.0 took four workflow attempts (see the failed attempts here). Two of the three timed-out pushes had published the pod anyway, and one had not.

Scope

• Before pushing a podspec, the step asks the CocoaPods Trunk API whether that version is published and skips the push if it is. This replaces the check for a duplicate-entry error that we had to add as a previous attempt to address this.
• After a failed push, the step checks again every 10 seconds for up to 2 minutes and moves on if the version shows up.
• If it never shows up, the step pushes again, up to 3 attempts, then fails the job.
• A version counts as published only when the Trunk API returns its record. An error, a timeout, or any other response counts as not published, so a bad response never skips a push.
• Nothing else in the workflow changes.

Testing

Unit testing

Not applicable, workflow-only change.

Manual testing

I ran the step's script locally with macOS bash 3.2 and a fake pod command:

• Against the real Trunk API, 5.8.0 skips both pods as it already exists. A version that does not exist gets 3 push attempts and then fails the job.
• With Trunk unreachable or not responding, a failed push retries 3 times and fails the job. A successful push passes.
• An error page or an empty response leads to a push, not a skip.

❗️ Not run in Actions yet. The next release is the first real run.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

🤖 Generated with Claude Code

[fadi-george]

In sdk-shared we have .github/actions/wait-for-cocoapods-pod but I guess its not really applicable here

[nan-li]

.github/actions/wait-for-cocoapods-pod

that's for the wrappers right. I can see if we can re-use it somehow for consistency

[nan-li]

.github/actions/wait-for-cocoapods-pod

that's for the wrappers right. I can see if we can re-use it somehow for consistency

Looked and this step and the wrappers wait-for-cocoapods is solving 2 different issues. The wrappers need to wait for someone else’s release to show up. This step decides whether to push. The other action polls the CDN for OneSignalXCFramework only, and the CDN trails Trunk by minutes, so it can’t tell the publish step whether to skip a push, so we can't reuse it in the same way here.