xcodebuild show issues: Cannot open "*.docc" as a "Swift Package Folder" because it is already open as a "Folder".}

[Wei18]

Xcode Version 14.0.1 (14A400)
Nuke version: 11.3.0

2022-10-05 00:09:10.089 xcodebuild[13166:8526635] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x60000bae4d00: name:NukeExtensions.docc path:group:NukeExtensions.docc> Failed to load container at path: /SourcePackages/checkouts/Nuke/Sources/NukeExtensions/NukeExtensions.docc, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "NukeExtensions.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "NukeExtensions.docc" as a "Swift Package Folder" because it is already open as a "Folder".}
2022-10-05 00:09:10.092 xcodebuild[13166:8526635] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x60000baeee00: name:Nuke.docc path:group:Nuke.docc> Failed to load container at path: /SourcePackages/checkouts/Nuke/Sources/Nuke/Nuke.docc, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "Nuke.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "Nuke.docc" as a "Swift Package Folder" because it is already open as a "Folder".}
2022-10-05 00:09:10.094 xcodebuild[13166:8526635] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x60000baefa00: name:NukeUI.docc path:group:NukeUI.docc> Failed to load container at path: /SourcePackages/checkouts/Nuke/Sources/NukeUI/NukeUI.docc, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "NukeUI.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "NukeUI.docc" as a "Swift Package Folder" because it is already open as a "Folder".}

[kean]

Can you please provide an example project?

[simawn]

I had a similar error on our CI with another project. Downgrading Xcode from 14.0.1 to 13.4.1 fixed the issue

[Wei18]

Hi @kean,
Sorry for lately replied and can't.
My apology.

[Sam-Spencer]

Just a heads up, our team at work is also experiencing this issue with other Swift Packages (e.g. Swift Protobuf) after upgrading our Azure CI pipelines to Xcode 14.0.1 and iOS 16 SDK. Can't say for certain, but it seems to be a bug on Apple's side of things. And, for what it's worth, from what we've been able to tell in our diagnosis of the issue you should be able to build and archive successfully regardless of the warning.

I had a similar error on our CI with another project. Downgrading Xcode from 14.0.1 to 13.4.1 fixed the issue -- @simawn

Our resolution was similar after a lot of back and forth with the folks at Azure. Seems like something undocumented changed in Xcode 14 with xcodebuild. We'll be trying again when Xcode 14.1 rolls out.

[gabors]

I have the same issue.
One this I don't understand though. I have used Xcode 14.0.1 since Sep 27 and builds have worked fine until few days ago.

[kean]

I'm able to reproduce it. There seems to be an issue with xcodebuild and .docc folders in package Sources/. It is the Apple recommended way to setup DocC for Swift packages. I fixed it in 11.3.1 by temporarily removing .docc folders from Swift packages.

[gabors]

I'm able to reproduce it. There seems to be an issue with xcodebuild and .docc folders in package Sources/. It is the Apple recommended way to setup DocC for Swift packages, but turns out it's broken in the current Xcode version. I fixed it in 11.3.1 by temporarily removing .docc folders from Swift packages.

Thanks so much 11.3.1 works great

[kean]

@Sam-Spencer

We'll be trying again when Xcode 14.1 rolls out.

I tried Xcode 14.1 RC and it's not fixed. Please upgrade to Nuke 11.3.1 that has a workaround for this issue.

[kean]

@gabors, @Sam-Spencer, can you please share your xcodebuild commands?

[gabors]

I was actually ok with Xcode 14.1 RC1 (didn't have a chance to try with today's RC2).
Prior to 11.3.1 update 14.1 RC1 was also ok for me, it showed that docc error, but it didn't fail the build.
With 11.3.1 the error was gone and builds were fine too.

[gabors]

@kean
Here is my command

xcb="/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild"

  $xcb \
    clean  \
    archive \
    -project "$SRC_DIR/WBTVD.xcodeproj" \
    -scheme $scheme \
    -configuration "Release" \
    -derivedDataPath "$DERIVED_DATA_DIR" \
    -clonedSourcePackagesDirPath "$CLONED_SRC_PKGS_DIR" \
    -archivePath "$ARCHIVE_DIR/$bundle_name/$bundle_name.xcarchive" \
    -destination $platform \
    -showBuildTimingSummary \
    "COMPILER_INDEX_STORE_ENABLE=NO" | xcbeautify

  $xcb \
    -exportArchive \
    -archivePath "$ARCHIVE_DIR/$bundle_name/$bundle_name.xcarchive" \
    -exportPath  "$ARCHIVE_DIR/$bundle_name" \
    -exportOptionsPlist "export-options/$BUILD_TYPE-$bundle_name-export.plist" | xcbeautify

I do not believe clonedSourcePackagesDirPath is necessary, was just trying things

[kean]

OK, I initially thought it was failing the build for some people, but looks like it isn't, is it? If it's not, I'll consider adding .docc sources back to the project.

Unfortunately, I can still see the (false positive) error messages when I install the previous version of Nuke and use xcodebuild in Xcode 14.1 RC. I don't want to pollute the builds with these errors.

[gabors]

Yeah I was also enjoying the build log without those docc errors.
I'm not sure what docc is used for TBH :) I just use GitHub for finding the documentation

[kean]

It contains additional documentation: articles, extensions for types, etc. When you click "Open in Developer Documentation" for the first time, it'll ask you to build the documentation. It uses these DocC files to generate the docs. Without them, you'll see only a subset of what's currently hosted on GitHub.

[gabors]

Ah very cool, looks really good.

[ahsan-storm]

Downgrading to Xcode 13.4.1 worked for me as well 👍

[Fab1n]

I really one to add one a solution here (for anyone with the same experience) which is really weird and crazy:
In my case the signing certificate has been expired and then this issue came up.
I renewed my distribution certificate and everything is back up again!

Cheers.

The real cause was NOT the .docc warnings for the build to fail, to make that clear.
Please check out the raw xcodebuild log, remove any log prettifier, like xcpretty, because they might swallow some error info.

[kean]

I'm going to put docc files back into the Sources/ folder in the upcoming release as this issue seems to be a false positive and doesn't affect the build. Hopefully the error message will be fixed in one of the upcoming Xcode release, if not already fixed.

[JackTudor96]

Hi all, I'm experiencing this issue on Nuke 11.5.0 on Xcode 14.2 during our CI builds.

2023-01-03 20:59:00.208 xcodebuild[20930:85749] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x600002ba6000: name:Nuke.docc path:group:Nuke.docc> Failed to load container at path: /Users/vagrant/Library/Developer/Xcode/DerivedData/-cqfcqwcyhdxloaawgpjvklqguajm/SourcePackages/checkouts/Nuke/Sources/Nuke/Nuke.docc, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "Nuke.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "Nuke.docc" as a "Swift Package Folder" because it is already open as a "Folder".}

2023-01-03 20:59:00.212 xcodebuild[20930:85749] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x600002ba9100: name:NukeExtensions.docc path:group:NukeExtensions.docc> Failed to load container at path: /Users/vagrant/Library/Developer/Xcode/DerivedData/-cqfcqwcyhdxloaawgpjvklqguajm/SourcePackages/checkouts/Nuke/Sources/NukeExtensions/NukeExtensions.docc, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "NukeExtensions.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "NukeExtensions.docc" as a "Swift Package Folder" because it is already open as a "Folder".}

2023-01-03 20:59:00.216 xcodebuild[20930:85749] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x600002ba9300: name:NukeUI.docc path:group:NukeUI.docc> Failed to load container at path: /Users/vagrant/Library/Developer/Xcode/DerivedData/cqfcqwcyhdxloaawgpjvklqguajm/SourcePackages/checkouts/Nuke/Sources/NukeUI/NukeUI.docc, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "NukeUI.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "NukeUI.docc" as a "Swift Package Folder" because it is already open as a "Folder".}

** ARCHIVE FAILED **

[kean]

It used to be an error message that wasn't failing the build. It looks like it depends on something else in the project setup.

There is a workaround to address the build failure: add -derivedDataPath to xcodebuild that points to somewhere outside of the project folder.

Update: I removed docc files again in 11.5.2 and will look for a better long-term solution.

[JackTudor96]

@kean thank you for that

[bengilroy]

Hi @kean – I work on the same project as @JackTudor96. We're still seeing the same issue on 11.5.2 unfortunately. We've also tried setting the GYM_DERIVED_DATA_PATH in our fastlane workflow but still getting the same issue as above – Cannot open "Nuke.docc" as a "Swift Package Folder" because it is already open as a "Folder.

[kean]

Tagged the wrong brach, sorry. Should now be fixed.

[bengilroy]

No worries! Is this for 11.5.2? If so, I've just run another build on our CI to test and still seeing the same issue but I'm not sure if I'm missing something. In the logs below you can see just before the issue occurs it's using 11.5.2.

Nuke - https://github.com/kean/Nuke.git @ 11.5.2
Cannot open "Nuke.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "Nuke.docc" as a "Swift Package Folder" because it is already open as a "Folder".}
2023-01-04 20:20:00.117 xcodebuild[10325:24350] [MT] IDEFileReferenceDebug: [Load] 
Cannot open "NukeUI.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "NukeUI.docc" as a "Swift Package Folder" because it is already open as a "Folder".}
Cannot open "NukeExtensions.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "NukeExtensions.docc" as a "Swift Package Folder" because it is already open as a "Folder".}
** ARCHIVE FAILED **

[bengilroy]

Hi @kean – it seems the issue has been resolved in 11.5.3 now, thanks for your help! 👍

[kean]

Tested in Xcode 14.3 beta – the issue still persists.

[kean]

Update: it appears to be a non-blocking issue. I tested it in the following project:

test-nuke-docc.zip

xcodebuild archive -scheme test-nuke-docc -configuration Release

There are also other reports, for example in swift-log that confirm that it's non-blocking.

Tools like xcpretty often hide the real build failure reason. For example, when I was testing it, I forgot to set-up signing and the output with xcpretty was the following:

2023-03-04 13:09:14.372 xcodebuild[11230:8233966] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x60000374de00: name:PulseUI.docc path:group:PulseUI.docc> Failed to load container at path: /Users/kean/Library/Developer/Xcode/DerivedData/test-pulse-docc-arvchnsawevpdlaqezsiwotyddpb/SourcePackages/checkouts/Pulse/Sources/PulseUI/PulseUI.docc, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "PulseUI.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "PulseUI.docc" as a "Swift Package Folder" because it is already open as a "Folder".}
▸ Clean Succeeded
** ARCHIVE FAILED **

If you remove xcpretty, it shows the real reason of the build failure:

/Users/kean/Desktop/test-pulse-docc/test-pulse-docc.xcodeproj: error: Signing for "test-pulse-docc" requires a development team. Select a development team in the Signing & Capabilities editor. (in target 'test-pulse-docc' from project 'test-pulse-docc')
** ARCHIVE FAILED **

[Fab1n]

I totally agree. This is just a warning when using xcodebuild, but it is not the real reason a build fails. It just looks like that, but you need to check the raw build log and will find the real build failure reason.

Regarding xcpretty: It should be replaced by xcbeautify.

[kamiluo]

Update: it appears to be a non-blocking issue. I tested it in the following project:

test-nuke-docc.zip

xcodebuild archive -scheme test-nuke-docc -configuration Release

There are also other reports, for example in swift-log that confirm that it's non-blocking.

Tools like xcpretty often hide the real build failure reason. For example, when I was testing it, I forgot to set-up signing and the output with xcpretty was the following:

2023-03-04 13:09:14.372 xcodebuild[11230:8233966] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x60000374de00: name:PulseUI.docc path:group:PulseUI.docc> Failed to load container at path: /Users/kean/Library/Developer/Xcode/DerivedData/test-pulse-docc-arvchnsawevpdlaqezsiwotyddpb/SourcePackages/checkouts/Pulse/Sources/PulseUI/PulseUI.docc, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "PulseUI.docc" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "PulseUI.docc" as a "Swift Package Folder" because it is already open as a "Folder".}
▸ Clean Succeeded
** ARCHIVE FAILED **

If you remove xcpretty, it shows the real reason of the build failure:

/Users/kean/Desktop/test-pulse-docc/test-pulse-docc.xcodeproj: error: Signing for "test-pulse-docc" requires a development team. Select a development team in the Signing & Capabilities editor. (in target 'test-pulse-docc' from project 'test-pulse-docc')
** ARCHIVE FAILED **

Thanks!. This solved my issue!!!.