Issue with Executing Unit Tests via CLI with swift-openapi-generator added to the package.

[kharezga]

Question

Issue with Executing Unit Tests via CLI with swift-openapi-generator added to the package.

Hello,

I am facing a challenge that hinders my ability to run unit tests through the Command Line Interface (CLI). The primary issue arises from my inability to exclude the swift-openapi-generator and _OpenAPIGeneratorCore during the "Link Binary with Libraries" phase. Notably, the unit tests run without any issues when executed directly within Xcode.

Background

The OpenAPI kit, inclusive of swift-openapi-generator, is solely incorporated within my networking-focused package/module, referred to as MyCoolModule. This configuration prevents the execution of unit tests via CLI. Despite efforts to integrate OpenAPI globally, this did not solve the problem. Below is a code snippet for additional context.

Core Issue

The difficulty seems to originate from the swift-openapi-generator's integration in the linking phase for my main target, attributed to its reliance on MyCoolModule. References to this issue can be found here and here. This dependency makes it impossible to exclude the mentioned components during the linking phase. As detaching "MyCoolModule" from the main target at this juncture is not feasible, I am in search of a workable solution that facilitates unit test execution through the CLI.

Note: OpenAPI is exclusively utilized and imported within the package, not added to the project on a global scale.

Output

Testing failed:
    _OpenAPIGeneratorCore is only to be used by swift-openapi-generator itself—your target should not link this library or the command line tool directly.
    Command SwiftEmitModule failed with a nonzero exit code
    Testing cancelled because the build failed.

MyCoolModule

let package = Package(
    name: "MyCoolModule",
    platforms: [
        .iOS(.v16),
    ],
    products: [
        .library(
            name: "MyCoolModule",
            targets: ["MyCoolModule"]),
    ],
    dependencies: [
        .package(name: "MyCoolNotRelatedModule", path: "../MyCoolNotRelatedModule"),
        .package(url: "https://github.com/apple/swift-openapi-generator", .upToNextMinor(from: "0.2.1")),
        .package(url: "https://github.com/apple/swift-openapi-runtime", .upToNextMinor(from: "0.2.0")),
        .package(url: "https://github.com/RocketLaunchpad/Keychain", .upToNextMajor(from: "1.0.0"))
    ],
    targets: [
        .target(
            name: "MyCoolModule",
            dependencies: [
                "MyCoolNotRelatedModule",
                .product(name: "OpenAPIRuntime", package: "swift-openapi-runtime"),
                .product(name: "Keychain", package: "Keychain")
            ],
            path: "./Sources",
            plugins: [
                .plugin(name: "OpenAPIGenerator", package: "swift-openapi-generator")
            ]),
        .testTarget(
            name: "MyCoolModuleTests",
            dependencies: ["MyCoolModule"]),
    ]
)

[czechboy0]

Hi @kharezga - you mention "Link Binary with Libraries", which is a concept used in Xcode projects, but you also provided a package manifest. Which are you using? Is there an Xcode project involved here? If so, do you have a small reproducer you could provide?

[kharezga]

Apologies for the insufficient detail previously. I am currently developing an iOS application, which is architecturally segmented into multiple modules. Among these, a specific module is designated for handling network operations, which extensively utilizes OpenAPI specifications for its functionality. My objective is to execute the unit tests for my iOS application through the CLI to facilitate seamless integration with my CI/CD pipeline.

At the moment, I have not prepared a minimal reproducible example to illustrate this scenario. However, I can create one if necessary for further clarification.

The structure of my project is outlined as follows, indicating the segregation of modules within the application:

[czechboy0]

Thanks for the clarification - since I suspect it's an issue with how the project is configured, I'm afraid I'll need you to create a smaller reproducer, and we can then figure out where the issue is.

[kharezga]

Hello @czechboy0, I've prepared a demonstrative project that encapsulates the issue we've been discussing. The project is available at the following repository.

Repro steps:

To reproduce the issue, please follow these steps within the repository's directory:

$ cd MyApp/MyApp/
$ xcodebuild \        
  -project MyApp.xcodeproj \
  -scheme 'MyApp' \
  -sdk iphonesimulator \
  -destination 'platform=iOS Simulator,name=iPhone 15,OS=17.2' \
  test

Note: For comparison, if you open Xcode and attempt to test the same scheme, everything works as expected without any issues.

I hope this information helps in isolating the problem. Looking forward to your insights and any further assistance you can provide.

[czechboy0]

Hi @kharezga,

I noticed in your sample project that you're using Swift OpenAPI Generator 0.2.x, which is over 6 months old.

Before I dig into the issue, can you please update to the latest version (1.2.x) and try again? It might already be fixed there.

Thanks

[kharezga]

Sure, I've bumped Swift OpenAPI Generator to version 1.2.1, but the problem remains unresolved.

[czechboy0]

Ok two changes you need to make this work:

1. Fix up the relative path in the Xcode project from ../../MyCoolPackage to ../MyCoolPackage
2. Don't pass the -sdk parameter to xcodebuild, just -destination. It seems to force the plugin to be built incorrectly when passed explicitly.

If you believe (2) is not correct behavior, please file an issue on Xcode through feedbackassistant.apple.com. Thanks!

[kharezga]

Indeed it works once I run the tests through the CLI, but once I do it with use od the Azure Pipeline's Xcode@5 I'm still facing the same issue since I'm not able to skip sdk parameter there. Anyhow, thank you but your guidance so far.

[czechboy0]

Right, at this point, there's not much we maintainers of Swift OpenAPI Generator can do here. You'll either need to ask for a way to skip the flag in your CI, or file an issue on Xcode, or both. But since this doesn't seem to be a problem with this project, closing this issue.

[kharezga]

Just for clarification, with use of the Fastlane script issue seems to be no longer valid and everything works fine.