Not sure if this will help anyone else, but just in case I'm posting how I was able to address it when I ran into this issue. The root cause was a conflict between a version specified in Package.swift and the Package.resolved file. The Package.swift file had just been updated to use the package(url:exact:) call for the dependency instead of package(url:from:) after running into an unrelated issue where local builds were using a newer version of a dependency than was specified in the Package.resolved file (so, what was used in Xcode Cloud). Unfortunately, Xcode wouldn't update the Package.resolved file after doing this change for some reason, and that fact was missed when those changes were checked in. I had to quit Xcode and run swift package resolve in terminal to get the file updated. Once this was checked in, the error was resolved. As a tangentially related side note - I was constantly running into differences between the Package.resolved file in the root of the project vs. the one inside the workspace. To get around this, the workspace version was added to the .gitignore, and then in Xcode Cloud's ci_post_clone.sh script I copy the root project into that location. Now I only have to worry about keeping one file up to date.

I'm seeing the same issue, though with a Reposilite server. Happened first about a month ago and it stopped pretty much all of our builds from working. It then just kind of resolved itself while I was looking into it. Now it just started erroring out again starting today, just randomly in some builds.

I've found a workaround for the issue that I'll be rolling out to the team soon - in short, move the package resolution up a step, and add retry logic. I grabbed a retry function from a Stack Overflow post (which apparently I can't link here, but you could find it pretty easy searching for details from the function below), dropped it into the ci_post_clone.sh script along with a call to do package resolution. Doing the package resolution here will cache the results so the later resolution done during the build phase doesn't need to go out to the internet and try to download them again. In my tests so far I've found that it usually resolves correctly by the 2nd or 3rd attempt. #!/bin/sh function fail { echo $1 >&2 exit 1 } function retry { local n=1 local max=5 local delay=15 while true; do "$@" && break || { if [[ $n -lt $max ]]; then ((n++)) echo "Command failed. Attempt $n/$max:" sleep $delay; else fail "The command has failed after $n attempts." fi } done } echo "Pre-resolving packages" retry swift package resolve

Seeing the same thing here. Our worst build that I'm aware of took 1h 55 minutes in the queue before it started, then before running tests inside the build was paused for another hour while it apparently waited for a free machine to run the tests. Others are all over the map, some taking approximately normal or just slightly more, some taking 2+ hours. The fact that the https://developer.apple.com/system-status/ page shows Xcode Cloud as green while it takes up to 3.5 hours to run what is normally a sub 30 minute build is ridiculous. I'm hoping this means that there are some infrastructure changes being done, but I won't hold my breath.

Saw the same here too. To clear it I had to drop down the version list and select the "Xcode 16.1 (16B40)" build again. If I had to guess, it has something to do with the "usage update" announcement - maybe there's a new "version" of that Xcode 16.1 release for Xcode Cloud. ¯_(ツ)_/¯