-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read Podfile dependencies from third-party-podspec #6086
Conversation
raise "Could not find node modules at given path #{rn_node_modules}" unless File.exist? rn_node_modules | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RuboCop suggests leaving an empty line after raise
for readability 😉
ios-xcframework/Podfile.lock
Outdated
@@ -674,6 +674,6 @@ SPEC CHECKSUMS: | |||
WordPress-Aztec-iOS: 7d11d598f14c82c727c08b56bd35fbeb7dafb504 | |||
Yoga: f7decafdc5e8c125e6fa0da38a687e35238420fa | |||
|
|||
PODFILE CHECKSUM: 1caec69a3de9c6e37113c8eb5dbdb2d2b52c5108 | |||
PODFILE CHECKSUM: 8f2b84cf5105963b4ef56ad18d6d64ab24334789 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notice the only change is in the checksum. This mean that the resolved dependencies with this new approach are exactly the same as before 🎉
The different checksum is due to the text content of Podfile
having changed.
ios-xcframework/Podfile
Outdated
podspec_extension = '.podspec.json' | ||
|
||
Dir["../third-party-podspecs/*#{podspec_extension}"].each do |podspec_path| | ||
pod_name = File.basename(podspec_path, podspec_extension) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be more robust to use the podspec json's name
property as the pod_name
, instead of the filename? We probably won't use a different name for the podspec.json file intentionally, but there might be a typo, omitting a dash (i.e. RCTFolly.podspec.json for the RCT-Folly pod), or something else, which would cause a mismatch between the filename and the pod name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done via f865eb5
So it's easier to find them in the `third-party-podspec` folder
I run `bundle exec pod install` to verify these removals didn't result in any change in the `Podfile.lock`, which they didn't.
The previous approach had them hardcoded. This is better because we now have a single source of truth. Hat tip @crazytonyli, see #5739 (comment) Notice that the only `Podfile.lock` change is in the checksum, meaning that the new logic results in the same resolved dependencies as before.
Co-authored-by: Tony Li <tony.li@automattic.com> See #6086 (comment)
a4762b3
to
f865eb5
Compare
Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job! |
Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job! |
1 similar comment
Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job! |
Nope! We are good at using |
I see React-related podspecs deleted, is this because of the XCFramework that they are not needed? We might need to update the bin/generate-podspecs.sh script to avoid adding them back whenever we update a dependency 🤔 |
@geriux thank you for mentioning that. I run |
No problem! I think if we just remove the |
The approach looks good to me Gio, thanks for working on this 🙇 ! The only caveat, as @geriux shared in #6086 (comment), we'd need to prevent re-generating the React-related pods in the |
@geriux @fluiddot I updated the script to generates the If one of you can confirm, I'll proceed with merging. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @mokagio for the improvements 🙇 !
I've only added a minor comment, that shouldn't block the PR but would be interesting to include to avoid adding an unnecessary pod.
Probably something for another PR, but I noticed we still have the logic that prompts us to run the generate-podspecs.
twice:
gutenberg-mobile/bin/generate-podspecs.sh
Lines 39 to 43 in 1261f7b
read -r -p "Enter the commit hash of previous commit. If this is the first-time running this script, enter 0, then commit generated files and re-rerun the script and this time use the previous commit hash: " COMMIT_HASH | |
if [[ -z "$COMMIT_HASH" ]]; then | |
echo "Commit hash cannot be empty." | |
exit 1 | |
fi |
gutenberg-mobile/bin/generate-podspecs.sh
Lines 148 to 155 in 1261f7b
# We are required to run this script twice to capture the correct target. | |
# 0 is the value set during the first script run to generate the podspecs. | |
if [[ "$COMMIT_HASH" != "0" ]]; then | |
echo 'Updating XCFramework Podfile.lock with these changes' | |
pushd ios-xcframework > /dev/null | |
bundle exec pod update | |
popd > /dev/null | |
fi |
I understand that this is no longer needed as the FBReactNativeSpec
pod is now generated in the XCFramework project, is this accurate?
Co-authored-by: Carlos Garcia <fluiddot@gmail.com>
I'll need to double check this and follow up if necessary. |
See https://github.com/wordpress-mobile/gutenberg-mobile/pull/6086/files#r1318224598 Co-authored-by: Carlos Garcia <fluiddot@gmail.com>
I noticed this because RuboCop barked at me for having a method with 11 SLOC instead of 10. However, I'm happy with the change. The implementation expects the file to be a JSON, so there's little value in making the extension configurable. If we changed that var to `.podspec`, the implementation would break!
c52c16c
to
8f9fb1c
Compare
# Conflicts: # ios-xcframework/Podfile.lock
Thanks for the |
Thanks for the `trunk` mereg @fluiddot. CI is green. I'll take your reaction as a 👍 to merge this. @mokagio To be honest, I couldn't fully test it last week when I shared those reactions. From the code perspective, the PR looks good to me but I was planning to generate an installable build as a double-check. Since CI is green let's keep this as-is and we'll test next week an installable build when we have more availability. Thanks 🙇 ! |
Thanks for the `trunk` mereg @fluiddot. CI is green. I'll take your reaction as a 👍 to merge this. I tested using the XCFramework and a local Gutenberg installation and haven't found any build and runtime errors 🎊. |
The previous approach had them hardcoded. This is better because we now have a single source of truth.
Hat tip @crazytonyli, see #5739 (comment)
Notice that the only
Podfile.lock
change is in the checksum, meaning that the new logic results in the same resolved dependencies as before.To test: Ensure CI is green.
PR submission checklist: