Xcode cloud build fails with Version 4.7.1

[xmanu]

Previously we used version 4.4.0 with Xcode 16.2 and this worked fine (locally and in Xcode cloud).
Because local builds failed, we updated this dependency to 4.7.1 and this fixed the issues locally.

Now the Xcode cloud build fails with the following error in the SwiftPackageListPlugin shell script phase:

Error: The file “workspace-state.json” couldn’t be opened because there is no such file.
LLVM Profile Error: Failed to write file "default.profraw": Operation not permitted
Command PhaseScriptExecution failed with a nonzero exit code

We already have configured Xcode cloud to skip the plugin validation (otherwise the builds wouldn't have worked before).

The Xcode version in Xcode cloud does not make a difference. We tried 16.2 and 16.3 (RC) (the full release is not available yet...).
Locally both work fine...

[FelixHerrmann]

Interesting... wonder what happens when you use the xcodebuild CLI locally, also from a fresh clone of the project.

Based on the error message it could be a sandbox restriction, you could try to disable that temporarily in Xcode Cloud with defaults write com.apple.dt.Xcode IDEPackageSupportDisablePluginExecutionSandbox -bool YES (like the plugin validation).

[xmanu]

Disabling plugin execution sandbox does change the error message slightly. it removes the second line:

Error: The file “workspace-state.json” couldn’t be opened because there is no such file.
Command PhaseScriptExecution failed with a nonzero exit code

I have to find out how to locally replicate the Xcode cloud build and will report back.

[xmanu]

I have isolated the issue:

On a typical build inside of Xcode, the --custom-packages-file-path is calculated as /Path/To/DerivedData/<Name of Derived Data Project>/SourcePackages
while on a Xcode cloud build (and a local xcodebuild build) it is reported as /Path/To/DerivedData/Build/SourcePackages.
This folder does not exist, as there is no intermediate folder in this case. The correct path should be /Path/To/DerivedData/SourcePackages.

I will create a PR that addresses this.

[FelixHerrmann]

Thanks for doing the investigation @xmanu! The change with 4.7.1 def. broke that but I think it was not always structured like that for xcodebuild builds.

From a none-plugin context (basically without the --custom-source-packages option) we also expect the .../DerivedData/<project>/SourcePackages location (https://github.com/FelixHerrmann/swift-package-list/blob/master/Sources/SwiftPackageListCore/Project/NativeProject.swift#L35) which should also be broken but I think we can get the patch in and released to unblock your (and likely other) setups and I will do some more investigation later this week.

[FelixHerrmann]

Release is done @xmanu

[xmanu]

Awesome! Thank you so much for the quick response and release! 🙇‍♂