Treat CocoaPods Trunk duplicate pushes as a no-op

[nan-li]

Description

One Line Summary

Treat already-published CocoaPods versions as a skipped no-op so the publish-release workflow can be re-run after a partial upload success.

Details

Motivation

Pushing to cocoapods with pod trunk push can return an internal server error after the version has already been accepted. Re-running the workflow then fails with Unable to accept duplicate entry, blocking the remaining steps of the workflow (XCFramework publish, SPM release, wrapper PRs). This change treats that duplicate as a no-op and emits a workflow warning so the skip is visible in Actions annotations.

Scope

Only .github/workflows/publish-release.yml CocoaPods publish steps. No SDK runtime behavior changes.

Testing

Unit testing

Not applicable — CI workflow-only change.

Manual testing

1. Release workflow for 5.3.0-beta-03 hit a cocoapods internal server error (but the version was already accepted) and returned early.
2. Re-running the workflow also returned early with failure due to duplicate version being uploaded
3. After fix: Re-ran publish-release for 5.3.0-beta-03: OneSignal Pod was skipped as a duplicate, and workflow continued successfully.

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
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• 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.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

Made with Cursor