Great! I think at best would be to have a look at the build logs on AppVeyor first and make sure all existing feature tests are green. A short list of issues I'm aware of.
#to_h. This is partially implemented and needs to be rebased.
whichcommand: Make sure command paths can be resolved - this is related to 2. and should be fixed first.
arubaon Windows if needed
I also added a platform tag to our issued tracker: https://github.com/cucumber/aruba/issues?q=is%3Aissue+is%3Aopen+label%3Aplatform%2Fwindows
@dg-ratiodata Had a quick look at the failing Windows specs.
To fix 2. and 4. I was thinking of re-implementing those commands as Ruby scripts (they are 2 or 3 lines each) to be executed by the specs so that they work in the same way on all platforms.
I believe that 7. should return what Ruby does, so Nil on Windows, and it should be tested.
@mattwynne I agree that having a docker base image is quite a good idea. I've had some troubles pinning down bugs in aruba with jruby - since I don't use rvm + only the latest mri ruby - so having a Docker image available is very welcome.
@e2 I like the idea to have
docker-compose, but is python required to run it?
excuse for absorbing more and more dependencies into the project.
I agree! Besides that, I think we need to find a balance between documentation and dependencies. All problematic dependencies are
I think we can handle this by flagging all scenarios with external deps as
@documentation-only or so. Then exclude them in a default cucumber run (cucumber.yml) and run them only in container/CI. I like the idea of having living documentation and don't want to "reduce" - sorry no better idea how to name it - our feature files' value for the project.
I think excluding them is a OK compromise.