Use ua-parser instead of browscap

[Krinkle]

Issue #143 laid the grounds for having a user agent parser. But I think we made the wrong choice on which parser that is.

The parser we chose is GaretJax/phpbrowscap (which gets its data from browscap.org's browscap.ini). The main problem with using that in TestSwarm context is that it means double maintenance. There is the maintenance of that .ini file, which is mostly upstream, our mapping in useragents.ini, and then your/our own subsets of that in testswarm.json to use in addjob.

Also, due to the nature of how browscap works, it requires each and every version to be handcrafted into the file. This makes that file huge and also causes it to naturally get outdated very often. More often than not, the user agent is (fortunately) in a predictable format. Although this format is different for each browser and/or platform, and it sometimes changes overtime, this can be kept track of just fine (which is what the us-parser project does).

By using variables the maintenance is a lot simpler. The only downside is that we can't output a fixed list "all supported browsers", because the parser will, as it is, detect Firefox 0.0 as well as Firefox 999.88 (in theory).

So we will likely drop maintenance of browserSets out of testswarm and leave that to the users of the software (we can provide a good sample of course).

An example of what this might look like in the end:

{
    "browserSets": {
        "popular": {
            "Chrome 19": {
                "browser": "Chrome",
                "major": 19
            },
            "Safari 5.1 (Mac)": {
                "browser": "Safari",
                "major": 5,
                "minor": 1,
                "os": "Mac OS X"
            },
            "Safari 5.1 (PC)": {
                "browser": "Safari",
                "major": 5,
                "minor": 1
            }
        }
    }
}

browserSets.foo.bar where foo is the freeform name of the set (to be used in addjob), and bar is the freeform ID of the browser (to be used in the database). And the properties of bar should correspond to the parser output of ua-parser (see readme).

TestSwarm would evaluate them in order of appearance so higher ones always have precedence.

[jayarjo]

In a node js module, that I'm currently working on, I've had an initial requirement of being able to request only specific browsers for the job. Sets are cool, but then maybe one doesn't need them all. I know TestSwarm was initially meant to be run on commit, but then why can't it be used on demand? Let's say in conjunction with BrowserStack, when only required browsers connect to the swarm, on request, run submitted jobs and disconnect, and on the other side user gets instant feedback in the console. In such scenario, requesting the whole set would be overkill. And defining the set is not possible through the API, right?

Will this change make possible what I've just described?

[Krinkle]

@jayarjo No, this feature request won't change that. This is about simply using a different User-Agent string parser. TestSwarm as it is now is meant for public continuous integration - not on-demand testing locally (which brings very different expectations, security and requirements for clients).

Primarily to get something like this: http://swarm.jquery.org/user/jqueryui

What you're talking about is a very different kind of system. However one of the long-term ideas I have is to create exactly that kind of system that you can use right from the command-line.

When used locally you'd:

• use a plugin to automatically set up a proxy to allow external access and use another plugin to automatically start browserstack clients.
• or you can just join with your local browsers

When done from the server (e.g. continuous integration on every commit)

• one wouldn't need the proxy (since the data is already on a server)
• use a browserstack plugin to start clients
• convert the output into a format that can be read by a continuous integration framework (e.g. Jenkins). so that instead of using pages like http://swarm.jquery.org/user/jqueryui and http://swarm.jquery.org/job/101, we'd use pages like https://integration.mediawiki.org/ci/job/MediaWiki-Tests-Databaseless/ and https://integration.mediawiki.org/ci/job/MediaWiki-Tests-Databaseless/2476/testReport/(root)/.

... thus effectively becoming sort of a "TestSwarm 2.0" without the database / GUI around it - and purely using it as an API to distribute tests to clients and extracting results from different unit test frameworks out of the clients in a uniform format back to the console.

Anyway, those are future plans :) If you are interested in that right now, perhaps check out Yahoo YUI Yeti with something like yeti bunyip - those seem headed in that direction.

[jayarjo]

Actually what I do is that I'm extending bunyip fork to work with testswarm... (yeti is not suitable in our case: https://github.com/ryanseddon/bunyip/issues/5) and in fact I do not see why this can't be achieved with what we already have here. The only obstacle that I currently see is that user can't add a job with just the browsers she needs. When you create a job from UI, you can check only specific browsers, right? Why do not extend this feature to an API as well.

[jayarjo]

Ahm... crap. Actually I checked now, and it seems that one can't. For some reason I remembered that this was possible... But anyway ability to make a set on the fly could be very useful, for BrowserStack users for example.

[jzaefferer]

One more reason to get this into place: Currently iPhone 5.0 (via iOS simulator) is detected as Safari 5.1. Same for iPad 5.0.

Until that is resolved we can't really get jQuery Mobile on TestSwarm. Though I'll probably go ahead with just running it against Chrome for now.

[Krinkle]

@jzaefferer Indeed, though they consider that bug to be a feature: GaryKeith/browscap#9.

[jzaefferer]

Uh, okay. I've read Gary's comments. Hey ho, let's go ua-parser?

[Krinkle]

I plan to work on this during my 9-hour flight tomorrow.