Skip to content
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

Merged
merged 13 commits into from
Sep 18, 2023

Conversation

mokagio
Copy link
Contributor

@mokagio mokagio commented Aug 18, 2023

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:

  • I have considered adding unit tests where possible. – N.A.
  • I have considered if this change warrants user-facing release notes more info and have added them to RELEASE-NOTES.txt if necessary. – N.A.

@mokagio mokagio requested a review from crazytonyli August 18, 2023 04:50
Comment on lines 15 to +17
raise "Could not find node modules at given path #{rn_node_modules}" unless File.exist? rn_node_modules

Copy link
Contributor Author

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 😉

@@ -674,6 +674,6 @@ SPEC CHECKSUMS:
WordPress-Aztec-iOS: 7d11d598f14c82c727c08b56bd35fbeb7dafb504
Yoga: f7decafdc5e8c125e6fa0da38a687e35238420fa

PODFILE CHECKSUM: 1caec69a3de9c6e37113c8eb5dbdb2d2b52c5108
PODFILE CHECKSUM: 8f2b84cf5105963b4ef56ad18d6d64ab24334789
Copy link
Contributor Author

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.

podspec_extension = '.podspec.json'

Dir["../third-party-podspecs/*#{podspec_extension}"].each do |podspec_path|
pod_name = File.basename(podspec_path, podspec_extension)
Copy link
Contributor

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.

Copy link
Contributor Author

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.
@mokagio mokagio force-pushed the mokagio/compute-podfile-dependencies branch from a4762b3 to f865eb5 Compare August 23, 2023 01:35
@peril-wordpress-mobile
Copy link

peril-wordpress-mobile bot commented Aug 23, 2023

Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job!

@peril-wordpress-mobile
Copy link

Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job!

1 similar comment
@peril-wordpress-mobile
Copy link

Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job!

@mokagio
Copy link
Contributor Author

mokagio commented Aug 23, 2023

@dcalhoun @geriux @SiobhyB @fluiddot

Is there anything I'm missing with this implementation that uses the contents of third-party-specs as the source of truth for which dependencies to include?

Thanks!

@geriux
Copy link
Contributor

geriux commented Aug 24, 2023

Is there anything I'm missing with this implementation that uses the contents of third-party-specs as the source of truth for which dependencies to include?

Nope! We are good at using third-party-specs as the source of truth 🚀

@geriux
Copy link
Contributor

geriux commented Aug 24, 2023

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 🤔

@mokagio
Copy link
Contributor Author

mokagio commented Aug 28, 2023

@geriux thank you for mentioning that. I run bin/generate-podspec.sh and it did in fact recreate the specs I removed. Clearly there's more work to do to centralize the source of truth.

@mokagio mokagio marked this pull request as draft August 28, 2023 01:27
@geriux
Copy link
Contributor

geriux commented Aug 28, 2023

@geriux thank you for mentioning that. I run bin/generate-podspec.sh and it did in fact recreate the specs I removed. Clearly there's more work to do to centralize the source of truth.

No problem! I think if we just remove the # Generate the React Native podspecs part within the bin/generate-podspecs.sh script we'd be set.

@fluiddot
Copy link
Contributor

Is there anything I'm missing with this implementation that uses the contents of third-party-specs as the source of truth for which dependencies to include?

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 generate-podspecs.sh script.

@mokagio mokagio marked this pull request as ready for review September 6, 2023 06:38
@mokagio mokagio requested review from geriux and fluiddot September 6, 2023 06:38
@mokagio
Copy link
Contributor Author

mokagio commented Sep 6, 2023

@geriux @fluiddot I updated the script to generates the third-party-podspecs to only generated the ones we currently need. The approach could do with some more work and optimization, but in my tests locally it did not generate additional or removed existing .podspecs.

If one of you can confirm, I'll proceed with merging.

@mokagio
Copy link
Contributor Author

mokagio commented Sep 7, 2023

image

I'll take those emoji reactions as confirmation. I just merged trunk into this branch to 1) update CI to match the new requirements (Lint and Unit Tests from Buildkite) and 2) verify locally that the script didn't change the third-party-podspecs content.

Enabling auto-merge

Copy link
Contributor

@fluiddot fluiddot left a 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:

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

# 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?

ios-xcframework/Podfile Outdated Show resolved Hide resolved
bin/generate-podspecs.sh Show resolved Hide resolved
bin/generate-podspecs.sh Show resolved Hide resolved
Co-authored-by: Carlos Garcia <fluiddot@gmail.com>
@mokagio
Copy link
Contributor Author

mokagio commented Sep 15, 2023

I understand that this [running pod install twice] is no longer needed as the FBReactNativeSpec pod is now generated in the XCFramework project, is this accurate?

I'll need to double check this and follow up if necessary.

mokagio and others added 2 commits September 15, 2023 14:28
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!
@mokagio mokagio force-pushed the mokagio/compute-podfile-dependencies branch from c52c16c to 8f9fb1c Compare September 15, 2023 04:30
@mokagio
Copy link
Contributor Author

mokagio commented Sep 15, 2023

@fluiddot @geriux I addressed your new suggestions, thanks again. I'd appreciate a final look over, just in case.

# Conflicts:
#	ios-xcframework/Podfile.lock
@mokagio
Copy link
Contributor Author

mokagio commented Sep 18, 2023

image

Thanks for the trunk mereg @fluiddot. CI is green. I'll take your reaction as a 👍 to merge this.

@mokagio mokagio merged commit 2e52634 into trunk Sep 18, 2023
@mokagio mokagio deleted the mokagio/compute-podfile-dependencies branch September 18, 2023 12:02
@fluiddot
Copy link
Contributor

image 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 🙇 !

@fluiddot
Copy link
Contributor

image 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 🙇 !

I tested using the XCFramework and a local Gutenberg installation and haven't found any build and runtime errors 🎊.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants