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

Use the same version as package.json in XCFramework #6101

Merged
merged 6 commits into from
Sep 5, 2023

Conversation

mokagio
Copy link
Contributor

@mokagio mokagio commented Aug 23, 2023

See @crazytonyli suggestion here: #5769 (comment)

To test: Check the value in the generated Info.plist, either by running npm run xcframework:build locally or by downloading and inspecting the CI artifact:

Screenshot 2023-08-23 at 8 49 33 pm

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 marked this pull request as ready for review August 23, 2023 10:52
@mokagio mokagio enabled auto-merge August 23, 2023 10:52
@crazytonyli
Copy link
Contributor

Thanks for taking my suggestion! What do you think about passing the version configurations to the xcodebuild command here?

Copy link
Member

@dcalhoun dcalhoun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test plan succeeded for me. 🎉 Thanks!

@mokagio
Copy link
Contributor Author

mokagio commented Aug 29, 2023

What do you think about passing the version configurations to the xcodebuild command here?

Thanks @crazytonyli !

I think that would work and it looks better that using PlistBuddy after the file has been created. At the same time, having the setting in the build script alone means we might lose it in case we change the automation (eg by moving to Fastlane). If it's as a build phase in the target, it will always run as long as we build the target.

Am I missing something?

@crazytonyli
Copy link
Contributor

The current solution looks good to me. But I'm not sure what responsibilities should the "scaffold" project holds. We now have build related tasks in both the build.sh shell script and the Xcode project's build phases. I just thought maybe we should consolidate the build related tasks in one place. The build.sh seems to be a good place for them. Also, we get to keep the scaffold Xcode project as lean as possible, which could be beneficial too.

BTW, I believe you can also pass build settings to fastlane actions too. Fastlane is usually backwards compatible with xcodebuild.

@mokagio
Copy link
Contributor Author

mokagio commented Aug 31, 2023

Also, we get to keep the scaffold Xcode project as lean as possible, which could be beneficial too.

Okay. I can stand behind that 👍

BTW, I believe you can also pass build settings to fastlane actions too. Fastlane is usually backwards compatible with xcodebuild.

Sure. I'm pretty sure that would be possible out of the box. My point was that with the settings in the xcodeproj they would automatically apply to a build call made from Fastlane.

mokagio added a commit that referenced this pull request Aug 31, 2023
Previously it was done via a build phase.
See this GitHub conversation for the rationale:
#6101 (comment)
@peril-wordpress-mobile
Copy link

peril-wordpress-mobile bot commented Aug 31, 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 31, 2023

@crazytonyli addressed your suggestion in e277e38

Thanks! 🙇‍♂️

Copy link
Contributor

@crazytonyli crazytonyli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking my suggestions! I have left a couple of comments which may help further simplify the solution.

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $version" "$plist"
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $version" "$plist"
fi
done
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This script is not used anymore, I think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I had forgotten about that one.

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 6d5a033

@@ -63,6 +66,9 @@ if [ ! -d $HERMES_XCFRAMEWORK ]; then
exit 1
fi

# Fail early if cannot fetch version
VERSION=$(./bin/get_gutenberg_version)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can use jq to replace this custom JSON parsing script: jq -e -r '.version' ./package.json?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered it, but decided against it to avoid having to ensure the tool is available locally.

Having said that... I guess it's safe to assume that to be the case and it doesn't take much to fail the script early if that's not the case 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 8779e2e


# get the path to the parent folder using Dir methods
package_name = 'package.json'
path_to_package_json = File.join(File.dirname(File.dirname(File.dirname(File.absolute_path(__FILE__)))), package_name)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do think using File.expand_path, instead of multiple dirname calls?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate on this suggestion?

The code uses File.dirname to have a platform-independent ... That is go up three parent folders.

There's no need for this to be platform-independent to be fair, but I find it a good habit to get into 🤷‍♂️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, addressing this is no longer necessary since the automation uses jq as of 8779e2e

mokagio added a commit that referenced this pull request Sep 1, 2023
Copy link
Contributor

@crazytonyli crazytonyli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@mokagio mokagio force-pushed the mokagio/xcframework-info-plist-version branch from 8779e2e to 9cb9689 Compare September 5, 2023 01:13
@mokagio mokagio merged commit 85151fd into trunk Sep 5, 2023
@mokagio mokagio deleted the mokagio/xcframework-info-plist-version branch September 5, 2023 02:13
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.

3 participants