Remove analysis failures for use_tree_artifacts_outputs flag

[luispadron]

We started using apple_*_xcframework_import rules to bring in XCFrameworks and we are getting failures during queries because of the use_tree_artifacts_outputs flag. We don't actually use the versioned macOS frameworks in our build, it's just shipped alongside the iOS framework and we have no control over this.

Because of the fail we needed to remove usage of the use_tree_artifacts_outputs flag, which causes a big regression in disk usage:

• bin/Code/Apps/App/App_archive-root/Payload/App.app (732 MB)
• bin/Code/Apps/App/App-intermediates/unprocessed_archive.zip (732 MB)
• bin/Code/Apps/App/App.ipa (740 MB)

With use_tree_artifacts_outputs flag enabled we only have:

• bin/Code/Apps/App/App_archive-root/Payload/App.app (732 MB)

We should see about better supporting this flag in the future, consider making it the default, or improve the disk usage without it.

In the meantime letting this fail later in the build allows folks who wouldn't actually hit the unsupported case to continue using the flag

[keith]

If you exclude them from the glob you would probably also sidestep this

[luispadron]

If you exclude them from the glob you would probably also sidestep this

Unfortunately the targets themselves are generated from rules_swift_package_manager which we don't have control over.

[luispadron]

If we have other approaches here I'm happy to take any we prefer over this, just trying to find a way to not block usage of the flag in cases where using the unsupported stuff isn't actually possible

[luispadron]

This is the error a user would see if they do try to use a versioned framework via apple_dynamic_framework on macOS (with this path):

  File "/private/var/tmp/_bazel_lpadron/d8d9324fa7fd2d11d5178d8cf2834c55/execroot/_main/bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/tools/bundletool/bundletool_experimental.runfiles/_main/tools/bundletool/bundletool_experimental.py", line 147, in run
    self._sign_bundle(output_path, code_signing_commands)
  File "/private/var/tmp/_bazel_lpadron/d8d9324fa7fd2d11d5178d8cf2834c55/execroot/_main/bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/tools/bundletool/bundletool_experimental.runfiles/_main/tools/bundletool/bundletool_experimental.py", line 307, in _sign_bundle
    raise CodeSignError(exit_code)
CodeSignError: Code signing failed with exit code 256
ERROR:

bazel-out/darwin_arm64-fastbuild-macos-arm64-min11.0-applebin_macos-ST-516b26a33bca/bin/examples/macos/HelloWorldSwift/HelloWorldSwift.app/: replacing existing signature
bazel-out/darwin_arm64-fastbuild-macos-arm64-min11.0-applebin_macos-ST-516b26a33bca/bin/examples/macos/HelloWorldSwift/HelloWorldSwift.app/: code object is not signed at all
In subcomponent: /private/var/tmp/_bazel_lpadron/d8d9324fa7fd2d11d5178d8cf2834c55/execroot/_main/bazel-out/darwin_arm64-fastbuild-macos-arm64-min11.0-applebin_macos-ST-516b26a33bca/bin/examples/macos/HelloWorldSwift/HelloWorldSwift.app/Contents/Frameworks/Lottie.framework

[luispadron]

I can also work on fixing that if you have tips, it looks like the Bazel issue the TODO is referencing has somewhat been resolved so potentially this is possible now

[brentleyjones]

That does look fixable. Ideally we would fix that before landing this change. If it's still broken only for RBE, I don't think we should block this change.