fix: work-around long path issues on windows

[dwgray]

Create a monkey-patch to get around the long filename issues on windows in the example. If I understand how the yarn patch works, we shouldn't have to do this for each example, but we'll probably want to document this and/or do a round with the react-native-vision-camera folks to see if they are willing to fix this on their end.

The core of the patch is to use a custom build of ninja.exe and tell it that we can have long path names. In order for this to work, you need to first enable long paths on windows. The quick way to do that is to run this reg file as admin and reboot.

The changes in the gradle file are under Windows-only build flags. I verified that it works on both Windows and Mac (and I verified that it failed on mac if I didn't put in the protection.

[cdiddy77]

Not sure why the ios build is failing. It might not be you

[dwgray]

Not sure why the ios build is failing. It might not be you

Yeah - I didn't touch the ios build at all (not that that's fullproof). If I'm reading the logs correctly, the error is

PhaseScriptExecution [CP]\ Check\ Pods\ Manifest.lock /Users/runner/Library/Developer/Xcode/DerivedData/objectdetection-epvaeodgotlmjmbjzuuweyfalevk/Build/Intermediates.noindex/objectdetection.build/Debug-iphonesimulator/objectdetection.build/Script-C38B50BA6285516D6DCD4F65.sh (in target 'objectdetection' from project 'objectdetection')
2024-04-11T16:05:23.4787540Z     cd /Users/runner/work/react-native-mediapipe/react-native-mediapipe/examples/objectdetection/ios
2024-04-11T16:05:23.4788670Z     /bin/sh -c /Users/runner/Library/Developer/Xcode/DerivedData/objectdetection-epvaeodgotlmjmbjzuuweyfalevk/Build/Intermediates.noindex/objectdetection.build/Debug-iphonesimulator/objectdetection.build/Script-C38B50BA6285516D6DCD4F65.sh
2024-04-11T16:05:23.4789230Z error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

I've noticed when building the ios version of the example that I end up with changes to podfile.lock and project.pbxproj - it looks like Suki pulled in some changes with #41, so maybe that's a clue?

[cdiddy77]

Not sure why the ios build is failing. It might not be you

Yeah - I didn't touch the ios build at all (not that that's fullproof). If I'm reading the logs correctly, the error is

PhaseScriptExecution [CP]\ Check\ Pods\ Manifest.lock /Users/runner/Library/Developer/Xcode/DerivedData/objectdetection-epvaeodgotlmjmbjzuuweyfalevk/Build/Intermediates.noindex/objectdetection.build/Debug-iphonesimulator/objectdetection.build/Script-C38B50BA6285516D6DCD4F65.sh (in target 'objectdetection' from project 'objectdetection')
2024-04-11T16:05:23.4787540Z     cd /Users/runner/work/react-native-mediapipe/react-native-mediapipe/examples/objectdetection/ios
2024-04-11T16:05:23.4788670Z     /bin/sh -c /Users/runner/Library/Developer/Xcode/DerivedData/objectdetection-epvaeodgotlmjmbjzuuweyfalevk/Build/Intermediates.noindex/objectdetection.build/Debug-iphonesimulator/objectdetection.build/Script-C38B50BA6285516D6DCD4F65.sh
2024-04-11T16:05:23.4789230Z error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

I've noticed when building the ios version of the example that I end up with changes to podfile.lock and project.pbxproj - it looks like Suki pulled in some changes with #41, so maybe that's a clue?

Where are you seeing these log errors? I guess they are in the raw logs, is that how you found them?

[dwgray]

Not sure why the ios build is failing. It might not be you

Yeah - I didn't touch the ios build at all (not that that's fullproof). If I'm reading the logs correctly, the error is

PhaseScriptExecution [CP]\ Check\ Pods\ Manifest.lock /Users/runner/Library/Developer/Xcode/DerivedData/objectdetection-epvaeodgotlmjmbjzuuweyfalevk/Build/Intermediates.noindex/objectdetection.build/Debug-iphonesimulator/objectdetection.build/Script-C38B50BA6285516D6DCD4F65.sh (in target 'objectdetection' from project 'objectdetection')
2024-04-11T16:05:23.4787540Z     cd /Users/runner/work/react-native-mediapipe/react-native-mediapipe/examples/objectdetection/ios
2024-04-11T16:05:23.4788670Z     /bin/sh -c /Users/runner/Library/Developer/Xcode/DerivedData/objectdetection-epvaeodgotlmjmbjzuuweyfalevk/Build/Intermediates.noindex/objectdetection.build/Debug-iphonesimulator/objectdetection.build/Script-C38B50BA6285516D6DCD4F65.sh
2024-04-11T16:05:23.4789230Z error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

I've noticed when building the ios version of the example that I end up with changes to podfile.lock and project.pbxproj - it looks like Suki pulled in some changes with #41, so maybe that's a clue?

Where are you seeing these log errors? I guess they are in the raw logs, is that how you found them?

The error is in the raw log file at line 46839. However, I found it by downloading the log archive (available from the gear icon from the build-ios results. That gave me a zip with more structured logs and I was able to drill down to the build_iod/8_Build example foriOS.txt log and find the error.

I just noticed that #61 failed the same job. And checking the log archives, it is failing in the same way, so it looks like we've got an intermittent error in our CI process (yuck). I'll do some digging on this today, but let me know if it's all right to run this job again to see what happened (I think you said there is a monetary cost per run)...

[dwgray]

Not sure why the ios build is failing. It might not be you

Yeah - I didn't touch the ios build at all (not that that's fullproof). If I'm reading the logs correctly, the error is

PhaseScriptExecution [CP]\ Check\ Pods\ Manifest.lock /Users/runner/Library/Developer/Xcode/DerivedData/objectdetection-epvaeodgotlmjmbjzuuweyfalevk/Build/Intermediates.noindex/objectdetection.build/Debug-

Where are you seeing these log errors? I guess they are in the raw logs, is that how you found them?

The error is in the raw log file at line 46839. However, I found it by downloading the log archive (available from the gear icon from the build-ios results. That gave me a zip with more structured logs and I was able to drill down to the build_iod/8_Build example foriOS.txt log and find the error.

I just noticed that #61 failed the same job. And checking the log archives, it is failing in the same way, so it looks like we've got an intermittent error in our CI process (yuck). I'll do some digging on this today, but let me know if it's all right to run this job again to see what happened (I think you said there is a monetary cost per run)...

If this SO answer is accurate, it looks like this error stems from podfile.lock and manifist.lock being out of sync, which shouldn't happen if pod install has been run in the build environment. Looking at the workflow file it appears that we won't run pod install if the pods are cached in either the turbo repro or cocoapods-cache. But of course if those caches are working correctly we shouldn't need to run pod install. I'm wondering if there is any possibility that one or the other of these mechanisms is mis-computing the hash that's used to decide if the pods are out of date?

One thing we could try is disabling one or both of those caches in the build system and see if this intermittent error disappears (we'd probably have to leave them off for a while). I'm not familiar enough with these systems to know what and how much we're getting out of these caches (probably build speed, but maybe it's cheaper as well)?