Closed artemyarulin closed 8 years ago
Looking at this and #25 I sense that the way forward might be to allow a complete escape latch instead of providing support for this features, since I'm likely to get them wrong. I still need to figure out how would that look like or how to give those scripts access to the runners (in case they need them).
Well, technically karma supports both of these features browsers/customLaunchers and files
And many more, so maybe will be easy just to allow user to pass karma config file and use it?
Not sure what kind of escape latch you're thinking of @bensu - users pass in a "custom runner" (let the lambdas loose)?
Supporting these two features directly seems OK to me (but I also get things wrong all the time)
doo.runner
If there is a simlper "escape hatch" that covers these cases though, that'd also be great :smile:
@artemyarulin yes, the escape latch might be just calling whatever runner you want with whatever arguments you want, thus letting you define your karma.config and running it.
@crisptrutski I'm not sure how this should look like. What I do know is that when it comes to config there is a world of needs that can't be covered with nice abstractions and feature requests like these two will pile up.
Fixed in 1de838f504a0eb88a1572fa4af47362f67c51ab9 (released under 0.1.6-SNAPSHOT
).
@artemyarulin, your original intent:
:doo {paths {:phantom "phantomjs --web-security=false" }}}
should now work for any number of options and you can find the relevant docs under Paths. Can you give it a try?
@crisptrutski it ended up being that all current runners could take the arguments before, so it was a rather small change to implement :) The only hiccup is that if the user passes bad options, some of the runners exit with 0 (signaling success) and now doo
needs to cover for that.
@bensu Works like a charm, thank you!
I wasn't able to find a way how to pass additional arguments to existings runners. For example if we specify
:doo {paths {:phantom "phantomjs --web-security=false" }}}
it will fail becausedoo
will check if executable exists first and with additional arguments it will fail to do so.One way could be adding additional arguments to
doo
settings or maybe it would be a better just to rely onkarma
and give user a way to specify a customkarma.config.js
, so it will be possible to configure a lot of things there.Currently I'm using the following workaround: project.clj
tests/phantom.sh