-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add step to run pod install
in XCFramework folder to automation
#116
Conversation
This is necessary after the introduction of the XCFramework builder project in wordpress-mobile/gutenberg-mobile#5739 and wordpress-mobile/gutenberg-mobile#5740. Worth noting that the XCFramework distribution pipeline and integration in Jetpack and WordPress iOS is currently incomplete. The step is required to avoid a CI failure but has not effect on the quality of the final release. This will hopefully change within the next couple of releases.
6b692c7
to
b5cf259
Compare
release_automation.sh
Outdated
# Update the Podfile for the XCFramework builder project | ||
# | ||
# We use a dedicated Xcode project to build the iOS distribution XCFramework which uses CocoaPods to fetch React Native dependencies and which references the project version. | ||
# It's necessary to keep the versions up to day in the project's lockfile. | ||
ohai 'Update XCFramework builders project Podfile.lock' | ||
cd ios-xcframework | ||
execute 'bundle' 'install' | ||
execute 'bundle' 'exec' 'pod' 'install' | ||
execute 'git' 'commit' '-m' "Release script: Sync XCFramework \`Podfile.lock\` with $VERSION_NUMBER" | ||
cd .. |
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.
Is there a straightforward way to test this in isolation?
For reference, here's a link to the ios-xcframework
folder in the gutenberg-mobile.
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.
Is there a straightforward way to test this in isolation?
Not really, but you can follow these testing instructions from the script. It mainly implies forking the repositories.
release-toolkit-gutenberg-mobile/release_automation.sh
Lines 3 to 33 in b5cf259
# INSTRUCTIONS FOR TESTING FROM FORKED REPOS | |
# Prerequisites: | |
# 1. Fork the following repos to your github user repo: | |
# a) Gutenberg-Mobile: https://github.com/wordpress-mobile/gutenberg-mobile | |
# * .gitmodules on CURRENT_BRANCH should reference your gutenberg fork, replace 'WordPress' with GITHUB_USERNAME | |
# * (https://github.com/wordpress-mobile/gutenberg-mobile/blob/trunk/.gitmodules) | |
# b) Gutenberg: https://github.com/WordPress/gutenberg | |
# c) WordPress-Android: https://github.com/wordpress-mobile/WordPress-Android | |
# d) WordPress-iOS: https://github.com/wordpress-mobile/WordPress-iOS | |
# 2. Insure that each of your forked repos contains the PR labels specified below: | |
GUTENBERG_MOBILE_PR_LABEL="release-process" | |
GUTENBERG_PR_LABEL="Mobile App - i.e. Android or iOS" | |
WPANDROID_PR_LABEL="Gutenberg" | |
WPIOS_PR_LABEL="Gutenberg" | |
# 3. Ensure that each of your repos contains the target branch listed below: | |
GUTENBERG_MOBILE_TARGET_BRANCH="trunk" | |
GUTENBERG_TARGET_BRANCH="trunk" | |
WPANDROID_TARGET_BRANCH="trunk" | |
WPIOS_TARGET_BRANCH="trunk" | |
# 4. Update the repo names below to the user repo name for your fork | |
GUTENBERG_REPO="WordPress" | |
MOBILE_REPO="wordpress-mobile" | |
# GUTENBERG_REPO="YOUR_GITHUB_USERNAME" | |
# MOBILE_REPO="YOUR_GITHUB_USERNAME" | |
# 5. Clone the forked gutenberg-mobile repo | |
# Before creating the release, this script performs the following checks: | |
# - AztecAndroid and WordPress-Aztec-iOS are set to release versions | |
# - Release is being created off of either trunk, or a release tag | |
# - Release is being created off of a clean branch | |
# - Whether there are any open PRs targeting the milestone for the release |
In my case, what I usually do is comment out parts of the script I don't want to be executed (e.g. PR/branch creation) and test locally.
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.
Thought so 😄
In my case, what I usually do is comment out parts of the script I don't want to be executed (e.g. PR/branch creation) and test locally.
Cool. I did that too and updated the PR description. I'm glad I did, because it reveal that I had forgotten to git add
the modified file.
release_automation.sh
Outdated
# Update the Podfile for the XCFramework builder project | ||
# | ||
# We use a dedicated Xcode project to build the iOS distribution XCFramework which uses CocoaPods to fetch React Native dependencies and which references the project version. | ||
# It's necessary to keep the versions up to day in the project's lockfile. | ||
ohai 'Update XCFramework builders project Podfile.lock' | ||
cd ios-xcframework | ||
execute 'bundle' 'install' | ||
execute 'bundle' 'exec' 'pod' 'install' | ||
execute 'git' 'commit' '-m' "Release script: Sync XCFramework \`Podfile.lock\` with $VERSION_NUMBER" | ||
cd .. |
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.
I chose to use execute
only for the bundle
and git
commands to be consistent with what the rest of the script does when calling cd
.
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.
LGTM 🎊 ! I tested the script locally and confirmed that ios-xcframework/Podfile.lock
was updated and committed. In my case, I tested bumping the editor version to 1.96.1
and got the following changes:
--- a/ios-xcframework/Podfile.lock
+++ b/ios-xcframework/Podfile.lock
@@ -386,7 +386,7 @@ PODS:
- React-Core
- RNSVG (9.13.6):
- React-Core
- - RNTAztecView (1.96.0):
+ - RNTAztecView (1.96.1):
- React-Core
- WordPress-Aztec-iOS (~> 1.19.8)
- SDWebImage (5.11.1):
@@ -601,7 +601,7 @@ SPEC CHECKSUMS:
RNReanimated: 8abe8173f54110a9ae98a629d0d8bf343a84f739
RNScreens: bd1f43d7dfcd435bc11d4ee5c60086717c45a113
RNSVG: 259ef12cbec2591a45fc7c5f09d7aa09e6692533
- RNTAztecView: 0d03d4841b9c2086bb2fe23d9069882b6528ab34
+ RNTAztecView: cd31152d7c144a834b2103a9b5d6cba5b442fb76
SDWebImage: a7f831e1a65eb5e285e3fb046a23fcfbf08e696d
SDWebImageWebPCoder: 908b83b6adda48effe7667cd2b7f78c897e5111d
WordPress-Aztec-iOS: 7d11d598f14c82c727c08b56bd35fbeb7dafb504
@mokagio I bumped into an issue when installing Pods in the XCFramework folder and generating the RN bundle (e.g. running npm command Error:
Seems Metro is trying to resolve React Native using the React package from one of the Pods. Maybe we could tweak the Metro configuration somehow to ignore it. I can try to take a look at this in the next few days. |
Thanks @fluiddot Ah, I run into that too and tried to make the automation ignore the Ultimately, I brushed that away assuming that "no one would need to use the XCFramework project locally," 😓 That's obviously an unsatisfactory conclusion. Fingers crossed you can sort it out 🤞 |
I think I forgot to mention that I ran into the issue after running the release script for testing this PR. So, I think that with this change we might start experiencing it after cutting a new release. Note that the script by default will install the Pods in the same Gutenberg Mobile project we use for development. I'll try to spare some time today on this and find out how to tweak Metro's configuration to ignore files/folders. |
I found a Metro configuration parameter to solve this, I created wordpress-mobile/gutenberg-mobile#5819 with the fix. @mokagio let me know if you could take a quick look, thanks 🙇 ! |
This is necessary after the introduction of the XCFramework builder project in
wordpress-mobile/gutenberg-mobile#5739 and wordpress-mobile/gutenberg-mobile#5740.
Worth noting that the XCFramework distribution pipeline and integration in Jetpack and WordPress iOS is currently incomplete. The step is required to avoid a CI failure but has not effect on the quality of the final release. This will hopefully change within the next couple of releases.
Update: I run a manual test after following @fluiddot's suggestion:
The script starts and eventually reaches the new step...
...which succeeds
This is the commit:
For reference, here's the diff for the modified version of the script that I used