I've started working on the next missing official API support endpoint from our list.

This time, List the build issues produced by an integration, is on a plate 🍛.

I've tried to run today XcodeServerSDK's iOS target I get this rather strange error:

It looks like our Podfile is linking wrong BuildaUtils target. Any idea what's wrong?

I'd like to add proper tests for requests/responses, so we need a library that helps us with that. I tried Mockingjay, unfortunately it doesn't yet have Swift 2 support. This is pretty urgent.

(cc: @cojoj and @esttorhe)

Hey, I added three tests for createRequest method, but I don't have a clue how to 100% cover the XcodeServerEndpoints class. Please take a look.

Btw. I have one proposition regarding XcodeServer class. I would move the code below (from sendRequestWithMethod method) to createRequest method, because createRequest method can figure out HTTP.Method directly from its parameter. What do you think?

var allParams = [
    "method": method.rawValue
]

//merge the two params
if let params = params {
    for (key, value) in params {
        allParams[key] = value
    }
}

@czechboy0 I hope you're back from holidays, full of energy and ready to work 😆

New batch with Device tests.

First of all, I've added missing fields/properties to Device model - please check them and let me know what do you think and if things marked as Enum? in comments should be moved to DeviceSpecyfication file.

One thing that concerns me about cassetes is that we're only testing gold path and skipping any possible error paths. Do you think we should create test cases and test failing paths as well? If so, how would you write those tests? Record another casette, write mocks or stubs? As we leave it as it is now we won't get full coverage of the code...

I've created tests for endpointURL method from XcodeServerEndpoints class. I set access level of XcodeServerEndpoints.endpointURL method as internal as we discussed in #79 issue.

I also renamed EndPoints -> Endpoints in XcodeServerEndPoints name in order to maintain the compatibility between names of files, classes and variables.

Please review.

Fix #33

Adds support for ᴡᴀᴛᴄʜ framework.

Dependencies

This PR depends on #32 (because its using the «new» throws/guard inits on the XcodeServerConfig class

While writing tests for this class I've noticed that it may be struggling in some cases.

First of all, when you create object using public init(var host: String, user: String?, password: String?) we're checking if host has https scheme and so on but if we go through the second init?() we can see that it won't check if scheme was provided - it only checks existence of host.

I think we should extract method for checking and creating host eg.

funct validateHost(var host: String) -> String{
    if let url = NSURL(string: host) {
        if url.scheme.isEmpty {
            // exted host with https scheme
            host = "https://" + host
        } else if url.scheme != "https" {
            Log.error("Xcode Server generally uses https, please double check your hostname")
        }
    }

    return host
}

But I think in this case we can make some use of throws and guard...

As I pointed in #45 I've witnessed some twisted behaviors of test coverage - indicates that not all of my code is covered while breakpoints execute in not covered part of code... Maybe some ideas?

Anyway, this code works fine and all tests are passing on both iOS and OS X.

In #1 @cojoj mentioned Carthage support. Let's look into how much would be required to properly support it, test out that our framework works both in iOS and OS X projects and if everything works, let's add the proper badge into our readme:

@cojoj, do you want to take care of this?

I'm working on another point from #40 and I want to consult some matters before implementing anything.

It's obvious that List the commits included in an integration will consist of Commit model but... Response JSON is strange in some way and I'd like to clarify naming convention. Basically integration/id/commits response JSON looks like:

{
    "count": 1,
    "results": [{
        "_id": "62395864c6d0b1fc6536c0ab3a0d2b2d",
        "_rev": "3-ced1cebb3b420512ee66e7a1927e32f2",
        "commits": {
                  []
                },
                "integration": "62395864c6d0b1fc6536c0ab3a0d0733",
        "botID": "38a6d8e59f34d59c810e98f5c6030e02",
        "botTinyID": "23530A6",
        "endedTimeDate": [2015, 7, 7, 14, 15, 20],
        "doc_type": "commit",
        "tinyID": "127FDC7"
    }]
}

IMHO, main object should be called something like IntegrationCommits because there's Commits array inside of it but Commit, itself, doesn't containt fields to be XcodeServerEntity. What's more, commits array contains an array of repositories which holds actual commits - so another model? Actual Commit looks like:

{
    "XCSCommitCommitChangeFilePaths": [{
        "status": 4,
        "filePath": "cells/NewProductCell.m"
    }, {
        "status": 4,
        "filePath": "GreetingTextViewController.m"
    }, {
        "status": 4,
        "filePath": "ViewControllers/NewChooseProductViewController.m"
    }],
    "XCSCommitMessage": "Fixed ios7 bug",
    "XCSBlueprintRepositoryID": "715A78DA7313BF688CEE0585F44D4F0B2EAEE4B8",
    "XCSCommitContributor": {
        "XCSContributorEmails": ["[email protected]"],
        "XCSContributorName": "Foo Bar",
        "XCSContributorDisplayName": "Foo Bar"
    },
    "XCSCommitHash": "aeb85aed37e633b6c9776cb863a39f922cb464d9",
    "XCSCommitTimestamp": "2015-07-07T14:14:29.000Z",
    "XCSCommitTimestampDate": [2015, 7, 7, 14, 14, 29]
}

I have a feeling I'm complicating everything but what do you think - should those models be separated or treated like one big, nested model and inherit from XcodeServerEntity?

In order to create a bot through the XCode Server API, is it required a first manual step to create the bot?

Inside https://honzadvorsky.com/articles/2015-08-04-xcs_tutorials_1_getting_started/ it says "One way to create Bots is directly from Xcode", so I'm wondering if it's possible to avoid the manual configuration. Our idea is to fully automatize the bot creation and its integrations.

That would warn us if any of the supported API calls changed responses - maybe use DVR and compare canned and live responses? First we'd wipe all bots, then inject known data and then query for it and compare.

Also, it'd be interesting to build a script which scrapes the internal .js files and creates a sorted list out of it, again would allow to quickly spot API changes (although it'd be ideal if Apple actually informed of the API version changes in the documentation).

In order to support https://github.com/czechboy0/Buildasaur/issues/180, we need to add a new object, XcodeServerProxy, which will look like a plain old Xcode Server on the outside, however on the inside it will talk to multiple real Xcode Servers, distribute work between them and when e.g. asked for Bots, will gather Bots from all real instances (and keep an internal map of which Bot lives on which instance).

This will get complicated, but is another step in powering awesome usecases which devs are coming up with - in this case, having a farm of Xcode Servers and distributing work between them.

All feedback is welcome, because I've never done anything like this. Should be fun.

(Note: this will require heavy tests to be written probably before we start implementing it to be able to lock down the behavior).

They're sort of out. Review and adapt some of our API calls (we might not be doing certain things properly).

https://developer.apple.com/library/prerelease/mac/documentation/Xcode/Conceptual/XcodeServerAPIReference/index.html