chore: Verify pod trunk publish after pod_push server errors - #1231
Merged
Conversation
NandanPrabhu
changed the title
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesRelease lane trunk verification
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@fastlane/Fastfile`:
- Line 18: The version check in Fastfile is using a substring match, which can
accept unintended versions. Update the `trunk_info.include?(version)` logic in
the version lookup flow to confirm an exact version entry from `pod trunk info`
rather than a partial string match. Use the existing `version` variable and the
surrounding `trunk_info` parsing code to compare against a discrete version
token or line match so only the intended version passes.
- Line 17: Handle the pod trunk info call in the Fastfile lane explicitly
instead of letting sh raise a FastlaneShellError. Update the trunk_info lookup
to use sh with an error_callback or block so transient trunk/network failures
are captured and the lane can continue to surface a UI.user_error! with a clear
publish-status message. Use the existing trunk_info logic in Fastfile to locate
the fallback path and keep the failure handling there.
- Around line 15-22: The trunk verification in Fastfile can fail too early
because pod trunk info may lag after a successful push. Update the release check
around the trunk_info lookup to retry with a short backoff before calling
UI.user_error!, and only fail after several attempts still do not find version.
Keep the success/failure handling in the same lane logic so Auth0 version
publication is confirmed reliably.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 26ef0206-6193-4800-8f39-85ecf5c2ece4
📒 Files selected for processing (1)
fastlane/Fastfile
sanchitmehtagit
previously approved these changes
Jul 1, 2026
sanchitmehtagit
left a comment
sanchitmehtagit
left a comment
Contributor
There was a problem hiding this comment.
LGTM. Lets look at coderabbit review comments too
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@fastlane/Fastfile`:
- Line 22: The `sh` call in `Fastfile` for `pod trunk info Auth0` is swallowing
useful error output via the no-op `error_callback`, which makes real failures
indistinguishable from missing propagation. Update this call so the
`error_callback` preserves or reports the command’s stderr in a way that keeps
the existing `trunk_info` flow intact, and use the `trunk_info` assignment site
to locate it.
- Line 22: The `trunk_info` lookup in `Fastfile` can hang indefinitely because
`sh` is calling `pod trunk info Auth0` without a timeout. Update the
`trunk_info` assignment to run the `pod trunk info` command through a shell
timeout (or equivalent guarded execution) so each retry fails fast instead of
stalling, and keep the change localized to the `trunk_info`/`sh` call path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 1f9aba17-6778-4a55-9ca8-26ae91868173
📒 Files selected for processing (1)
fastlane/Fastfile
…pod trunk info command
utkrishtsahu
approved these changes
Jul 1, 2026
sanchitmehtagit
approved these changes
Jul 1, 2026
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@fastlane/Fastfile`:
- Around line 24-29: The `trunk_info` error handling in `Fastfile` is calling
`.message` on the `error_callback` argument from `sh`, but that callback
receives the command output string rather than an exception. Update the `sh("pod
trunk info Auth0", ...)` `error_callback` block to log the string directly, and
keep the `Timeout.timeout`/`rescue Timeout::Error` retry path intact so a
non-zero `pod trunk info` exit does not abort the flow.
- Around line 24-29: Replace the Timeout.timeout wrapper around the trunk_info
probe with a process-level timeout approach inside the Fastfile logic. The
current use of sh("pod trunk info Auth0", ...) should be updated to use a
Fastlane-native timeout or explicit subprocess kill/cleanup path so the pod
command itself is terminated reliably. Keep the existing trunk_info handling and
error_callback structure, but move timeout enforcement out of Timeout.timeout
and into the command execution path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 21749a31-5455-4bee-bbac-5e84481d9862
📒 Files selected for processing (1)
fastlane/Fastfile
Contributor
Author
|
@coderabbitai full review |
✅ Action performedFull review finished. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📋 Changes
Cocoapods publish can fail intermittently with server error while pod is published. Added code in fastfile to print pod trunk list for listing the version published ensuring even if server error returned during publishing the pod is actually published
📎 References
🎯 Testing
Summary by CodeRabbit