Add :stack to Job::Queue

[svenfuchs]

I have also refactored Job::Queue a little bit to remove all the repetition in matches_something? that we've had.

[sarahhodne]

Why not just queue.matches?(config)?

[svenfuchs]

For some reason all the instance methods are private, not sure why

[svenfuchs]

@henrikhodne made it public

[sarahhodne]

I think this is fine as it is, but here's a Ruby tip of the day: Enumerable#detect takes an argument that's used if nothing matches, so this could be written as:

queues.detect(default) { |queue| queue.matches?(config) }

[svenfuchs]

nice one, will use that

[svenfuchs]

Can we merge this? :)

[svenfuchs]

Added a feature flag for this (per owner) and tested on staging.

[joshk]

Can you explain how :stack is supposed to be used? Is it specified in the .travis.yml or in the hub config? Why would :stack be used used vs the other routing means?

[svenfuchs]

@joshk during beta we whitelist repo owners using a feature flag. people can then opt in to using docker by setting stack: docker in their .travis.yml

All of language, os, stack currently behave exactly the same: if a queue defined in the gatekeeper config matches the attribute given in .travis.yml then the queue name from the gatekeeper config is used for the build.

The reason to pick stack over os was that potentially we might offer other OS's to run in Docker. Docker just isn't an OS ... and we couldn't come up with a better name for the flag. virtualization was discussed, but seemed too clunky.