Builder: mongo-swift-driver false negative

[finestructure]

The issue is that xcodebuild currently fails to pick up cSettings

The fix is to either pass the settings explicitly to xcodebuild:

xcodebuild -scheme MongoSwift GCC_PREPROCESSOR_DEFINITIONS="MONGO_SWIFT_OS_DARWIN BSON_COMPILATION MONGOC_COMPILATION”

or to build via swift build

[finestructure]

To summarise, I think our options are:

1. Somehow pass in explicit settings (via a metadata file for instance, or plain special casing of certain packages)
2. Short-circuit certain packages we know are problematic but where we agree to accept an upstream signal
3. Try swift build if xcodebuild failed
4. Wait for the Xcode build fix

[finestructure]

I think 4. could be an option if we know it’s close - i.e. in Xcode 12. However, that seems unlikely, since Xcode 12b2 is also failing.

Option 3. isn’t great, as it complicates the build further and increases run times for every failed build (which are many). We could/should limit this to macOS, which might help here. Or turn it around, run swift build first and then xcodebuild? Not sure if there are risks of false positives or if there are even gains to be expected.

[finestructure]

Re 2.: Given the SSWG minimal requirements for sandbox level projects and above, there’s an argument to be made to fast-path the projects from the Swift Server Ecosystem Index and report them supporting latest macOS/Linux.

[daveverwer]

So, given that we're going to need a swift build path through the builder tool in order to support Linux builds I think the best option is to simply add another column to our build permutations table.

We currently have:

When we add Linux support, we will then need something like this:

Given that we'll already have the command structure for building packages with swift build at that point, I think we could justify adding one more column:

[daveverwer]

To give an opinion on all these, I'd place them in this order from my favourite, to least favourite:

3. Try swift build if xcodebuild failed

Except, I wouldn't do it conditionally. Let's just run one more build for everything as I mention above.

1. Somehow pass in explicit settings (via a metadata file for instance, or plain special casing of certain packages)

Yep, I think this may potentially be necessary for some real edge cases that we have yet to see, but I bet they're in there somewhere.

2. Short-circuit certain packages we know are problematic but where we agree to accept an upstream signal

I'm happy to short circuit packages, but this does weaken the feature in that the matrix is no longer only showing build results, but build results and special cases.

4. Wait for the Xcode build fix

This could be a long time coming.

[finestructure]

Just triggered via

    post build macos (spm):
        url: ${base_url}/api/packages/${package}/trigger-builds
        method: POST
        headers:
            Authorization: Bearer ${builder_token}
        body:
            json:
                buildTool: spm
                platform:
                    name: macos
                    version: "x86_64"
                swiftVersion:
                    major: 5
                    minor: 2
                    patch: 4
        validation:
            status: 200

and all three refs are passing now:

• https://gitlab.com/finestructure/swiftpackageindex-builder/-/jobs/649059159
• https://gitlab.com/finestructure/swiftpackageindex-builder/-/jobs/649059161
• https://gitlab.com/finestructure/swiftpackageindex-builder/-/jobs/649059166

https://staging.swiftpackageindex.com/mongodb/mongo-swift-driver/builds

[finestructure]

I’ll retrigger the rest as part of a full rebuild asap.