-
Notifications
You must be signed in to change notification settings - Fork 114
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 quick check for nested frameworks #4226
Conversation
ad7ce9b
to
6f32c0c
Compare
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
You can trigger an installable build for these changes by visiting CircleCI here. |
I think we can add this as a Run Script phase, so we catch the error locally and not just on CI. This seems to work, although I'm not too familiar with build environment vars to know if NESTED_FMKS=$(find "${TARGET_BUILD_DIR}"/WooCommerce.app/Frameworks/*.framework -name Frameworks)
if [ -n "$NESTED_FMKS" ]; then
echo "error: Found some nested frameworks inside Frameworks/*/Frameworks subdirectories. Such a configuration is invalid and will be rejected by TestFlight. Please fix by choosing 'Do Not Embed' for the nested framework in the Xcode project of the parent framework containing it"
echo $NESTED_FMKS
exit 1
fi |
Oh that's a good point and good idea 👍 Yeah will try as a build phase indeed! |
Updated the PR to use a Script Build Phase, and this is what it looks like in Xcode when it finds nested frameworks: And as a bonus, here's the expected build failure on CI too when the fix hasn't been applied yet:
I'm gonna rebase that branch on top of the fix now to double-check that the script goes green and doesn't error anymore once fixed. |
); | ||
runOnlyForDeploymentPostprocessing = 0; | ||
shellPath = /bin/sh; | ||
shellScript = "# Nested frameworks (i.e. having a Frameworks/ folder inside *.app/Frameworks/.framework) is invalid and will make the build be rejected during TestFlight validation. But this can happen especially due to an Xcode 12.4 UI bug when linking binary frameworks to the project which always embed the binary (bug that is fixed in Xcode 12.5)\n\nNESTED_FMKS=$(find \"${TARGET_BUILD_DIR}\"/WooCommerce.app/Frameworks/*.framework/Frameworks -name '*.framework') \nif [ -z \"$NESTED_FMKS\" ]; then\n echo \"✅ No nested framework found, you're good to go!\"\nelse\n for f in $NESTED_FMKS; do\n nested=$(basename $f)\n parent=$(basename $(dirname $(dirname $f)) .framework)\n echo \"error: Found nested framework in $f -- Such a configuration is invalid and will be rejected by TestFlight. Please fix by choosing 'Do Not Embed' for the nested framework \\`$nested\\` within the \\`$parent\\` Xcode project containing it. You might need to use Xcode 12.5 to fix this, due to an Xcode 12.4 bug – see paNNhX-ee-p2\"\n done\n exit 1\nfi \n"; |
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.
@koke Seems like using $TARGET_BUILD_DIR
was the right decision, according to my favorite Build Settings reference 👍 :
Run Script build phases that operate on product files of the target that defines them should use the value of this build setting.
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.
Following up on the comment above, having the run script in an actual script also makes it simpler to read and edit it, as well as having a sensible diff to look at as opposed to a single very long line (:xcode:
)
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.
Yeah I agree that I could have extracted that script into a file in Scripts/….sh, to make it more readable and diff-able 👍
That's actually something I usually do so not sure why I didn't that time around 😺
42f7214
to
581c114
Compare
Retrospective P2 post here for reference: paNNhX-ee-p2 |
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.
Default behavior:
Hacked behavior to force failure:
👍
One nitpick
I found the error output from find
before the successful setup message confusing. "Why am I seeing something that looks like an error when the log tells me everything is fine? 🤔"
Have you considered forwarding find
's output to /dev/null
?
); | ||
runOnlyForDeploymentPostprocessing = 0; | ||
shellPath = /bin/sh; | ||
shellScript = "# Nested frameworks (i.e. having a Frameworks/ folder inside *.app/Frameworks/.framework) is invalid and will make the build be rejected during TestFlight validation. But this can happen especially due to an Xcode 12.4 UI bug when linking binary frameworks to the project which always embed the binary (bug that is fixed in Xcode 12.5)\n\nNESTED_FMKS=$(find \"${TARGET_BUILD_DIR}\"/WooCommerce.app/Frameworks/*.framework/Frameworks -name '*.framework') \nif [ -z \"$NESTED_FMKS\" ]; then\n echo \"✅ No nested framework found, you're good to go!\"\nelse\n for f in $NESTED_FMKS; do\n nested=$(basename $f)\n parent=$(basename $(dirname $(dirname $f)) .framework)\n echo \"error: Found nested framework in $f -- Such a configuration is invalid and will be rejected by TestFlight. Please fix by choosing 'Do Not Embed' for the nested framework \\`$nested\\` within the \\`$parent\\` Xcode project containing it. You might need to use Xcode 12.5 to fix this, due to an Xcode 12.4 bug – see paNNhX-ee-p2\"\n done\n exit 1\nfi \n"; |
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.
Following up on the comment above, having the run script in an actual script also makes it simpler to read and edit it, as well as having a sensible diff to look at as opposed to a single very long line (:xcode:
)
@mokagio I can't forward the output of find to |
I think the error on success is because the I think this should work instead: find "${TARGET_BUILD_DIR}"/WooCommerce.app/Frameworks -name Frameworks -depth 2 |
+ fix misleading message when no nested framework
d6e8860
to
e72ad46
Compare
This is now fixed – and also extracted in a dedicated script file as @mokagio suggested 🎉 I had to tweak the script a bit more so that the error messages were still nice with this new result format of the new |
echo "❌ Found nested \`Frameworks\` folder inside frameworks of final bundle." | ||
for fmk_dir in $NESTED_FMKS_DIRS; do | ||
parent_fmk=$(basename $(dirname $fmk_dir) .framework) | ||
nested_fmks=$(cd "${fmk_dir}" && find . -name '*.framework' -depth 1 | sed "s:^./\(.*\)$:\`\1\`:" | tr '\n' ',') |
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.
-depth 1
here is so that ifNetworking.framework
is embed inYosemite
butCodegen
is also embed inNetworking
, we don't want to print about the 2nd level ie theWooCommerce.app/Frameworks/Yosemite.framework/Frameworks/Networking.framework/Frameworks/Codegen.framework
– since the nesting of Codegen within Networking will already be printed as a separate error- The
sed
call is to get rid of the./
at the beginning of each output line offind . -name …
, and also to quote each line between a pair of backticks - The
tr
call is to join all the lines with a,
. This will add an extra,
at the end of the list, but we'll get rid of this by using bash substitution${nested_fmks%,}
when printing the list line 17, to get rid of the suffixed comma.
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 suggestion.
93cac05
to
eff300e
Compare
Following the issue we had with TestFlight validation and nested frameworks introduced by the Xcode 12.4 bug (see paNNhX-ee-p2 for details), this check will hopefully catch if we encounter such a configuration issue again later.
To test
I already tested this myself (see comments below) but it could be nice to validate the check works on other's machines too.
To test this:
Run custom shell script 'Check for nested frameworks'
step at the end and check that it says✅ No nested framework found, you're good to go!
Yosemite
project in the workspace, go to the "General" tab, and in the "Frameworks and Libraries" section, change the line forCodegen
from "Do Not Embed" to "Embed & Sign"