by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Paolo Ambrosio
@paoloambrosio
For 7. I believe that stat on Windows does not expose the block size. From the macro hell that is the filesystem API on the MRI, this might be the data structure used: https://msdn.microsoft.com/en-us/library/14h5k7ff.aspx
Paolo Ambrosio
@paoloambrosio
About 1. instead as @jarl-dk says it depends on the FS, and not just on the OS. On Linux FAT32 and NTFS are even worse than on Windows! I believe that the Aruba specs should check that permissions can be changed, and not the behaviour of the RVM, the OS or the FS.
I would design the test suite assuming that it is run on the standard filesystem for the platform (any "standard" filesystem on Linux and OSX, and NTFS on Windows). For example I wouldn't do anything that might fail in the case-insensitive filesystem in OSX. We should be able to find a representative superset that works on all common combinations of FS and OS.
Paolo Ambrosio
@paoloambrosio
And again about 7. why was that functionality ever implemented? Should Aruba be concerned with those details?
Dennis Günnewig
@maxmeyer
@paoloambrosio Wow! :smile: Thanks a lot about getting into this. First one quick question: Where do 1., 2. ... refer to? Build errors? About 7: Normally I add things I need myself and think they're useful for others as well, but I can't remember for what project I added the block size thing. But I think I hat in mind, that windows does not support this kind of functionality and should raise "NoImplmented"-error or so.
If you like, send me a PR for your changes. We then can pair on this. Just push the branch to the aruba/repo.
I'm really glad that you found some time to have a look into this.
I hope we can fix the problems for windows once and for all... at least for the current functionality ;-)
Cezary Baginski
@e2
I'll just be sharing thoughts and feedback here - mostly on the recent PRs I've made.
First, I think Aruba tests shouldn't run any apps it doesn't own. This includes using bash, zsh, echo and related for shell. It would be much better to have ruby bash/zsh "shim" that just supports the given "OS feature". The other extreme would be to just run all tests in Docker - which would guarantee consistency without endless workarounds and issues related to "local setup". This is because Travis is not a good place for "development".
Cezary Baginski
@e2
I just added a PR with a Docker workflow: cucumber/aruba#353 . Ideally, there should be an "offical" Aruba base image for testing (all code up to the JDK install included) - and the one here would just include it and build off from there. (Provisioning with gems, etc.).
Dennis Günnewig
@maxmeyer
Sounds good. Will see what I can do. @mattwynne @aslakhellesoy Do we have a cucumber org on docker hub I can use for this?
Cezary Baginski
@e2
For blocks counting on Windows, I'd just either approximate it (cluster size * (1+file_size/cluster + file_count + dir_count)) or expect a tool like du.exe to be installed. (But, for the latter, there's a sever limit to the argument size for a command on Windows, so that complicates things). I'm sure users would prefer an approximation rather than a perfectly accurate implementation no one will ever implement in Ruby...
Dennis Günnewig
@dg-ratiodata
@e2 wee need to be careful otherwise merging all your work into release/1.0.0 will be really really hard and my not possible any more!
Cezary Baginski
@e2
@dg-ratiodata - it's mostly bugfixes and new features (like Docker), so there shouldn't be any conflicts. If that's an issue, it's best to switch master to 1.x, branch off 0.14 for backporting, and just focus on releasing 1.x ASAP. It's no problem to then work on 2.x a month from now - no one will complain because of "too many major releases". Aruba is complex, so learning is expected. And if learning is reflected in "multiple major releases", that's just an indication of how much learning (or rework) was needed, nothing else. I'm guessing it's actually more useful to just skip to 2.x (master - without releasing), branch off 1.x as unreleased as "work in progress" (too keep the branches). E.g. I'm (as a contributor) only interested in master and not backward compatibility or deprecations - so it makes no sense to add an artificial "burden" on master. You can always work on a "transition release" - but only if there's a genuine need in the community. Master branch should be optimized for quickly accepting PRs. (If PRs don't have priority over other work, contributing feels very discouraging - as if there's a ton of "bureaucracy"). It doesn't make sense to expect contributors to make backports of their own fixes (that they don't need themselves).
@dg-ratiodata - if there's a lot of scrunity for PRs on master (like now), there's no need for a release/1.0.0 branch. Release branches don't fix a discipline/quality problem, they only create a branch managing problem. (Especially if plans aren't communicated to contributors effectively).
Dennis Günnewig
@dg-ratiodata
@e2 I made an issue from your comment.
cucumber/aruba#363
Paolo Ambrosio
@paoloambrosio
re running tests in docker: are you expecting that to work for Linux only or to use a Windows container on Windows? I don't understand much what docker would solve
Dennis Günnewig
@dg-ratiodata
@paoloambrosio Good point. From my understanding - current state of discussion - It will only solve problem for developers developing on Linux. We will still have issues on Windows. And we need a fix for that. I cannot think of a container solution for windows which has no licensing issues beside the fact that there is none so far - from my knowledge.
Since I'm not developing on Windows we need developers from that area to describe their need...
As for the introduction of docker: I thought about that for a different internal project myself and implemented that. This worked quite well and reduced the setup "costs" for external developers, so I think adding Docker to the repo still has some value
I hope to find some time during the weekend to wrap my head around the dev xp things - on a higher level - to form a "vision".
Dennis Günnewig
@dg-ratiodata
AND: Finally I would have got a platform to troubleshoot jruby issues since I'm not a fan of using rvm
Matt Wynne
@mattwynne
IMO given a choice, I would prefer to slim down Aruba and try to reduce the dependencies rather than making the build more complex. Having said that, if there are some dependencies we’re agreed we do really need that are fiddly to install then I think having a Docker build is a good idea - anything that makes it easy to get a developer up and running is great. Thanks for the suggestions @e2!
Cezary Baginski
@e2
@mattwynne - right now, if I want all tests to be green on my desktop, I have no other choice than to use Docker. There are pending PRs, but juggling them while rebasing over new stuff would mean "unrelated" breakages from other issues. Nothing is worse than failing tests. Also, the build isn't complex - it's just Docker was added as an option, beside the current build. It would also allow Windows users to run Linux tests on their machines - directly using their checked-out sources. (So they can rework Windows-platform specific stuff and immediately test on Ubuntu/Docker if they broke anything on the other side. (All before sending a PR to trigger a Travis build). Technically this allows allows testing things on specific patch versions of a given Ruby. And you can run multiple containers with isolated tests, with different sets of gems. Also, if anyone reproduces a weird issue in a docker image, it's not a problem to upload/download ... and roll up your sleeves to start investigating. And with Docker Compose I'd argue it's actually easier than using Rake tasks for it...
@mattwynne - as for "slimming down", I'd focus on the codebase. It's not like Aruba is suffering for an overwhelming amount of dev tools inside. Meanwhile, Ruby 1.8.7 support is still there - along with lots of other deprecations. There's no use putting effort into slimming anything else down that what's needed to release 1.x. And then e.g. increasing test coverage and other improvements.
Matt Wynne
@mattwynne
@e2 sure - I think Docker gives us some great options, I just wouldn’t want it to become an excuse for absorbing more and more dependencies into the project. For example, I don’t like the fact that there are steps / helper methods that assume the user will have RVM or Bundler installed. I think those should move out intro a contrib gem.
By the way, one of our biggest users is the RSpec project, who need 1.8.7 support since many of their users still use 1.8.7 and they want to keep supporting them.
Dennis Günnewig
@maxmeyer

@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?

Cezary Baginski
@e2
@maxmeyer - file bin/docker-compose
bin/docker-compose: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=00747fe5bcde089bb4c2f1ba7ab5348bc02ac5bf, stripped
Dennis Günnewig
@maxmeyer
Great! :-) Thanks.
Dennis Günnewig
@maxmeyer

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

  1. introduced by me (while improving our documentation)
  2. are part of our documentation (aka features) to demonstrate that aruba can run bash-scripts, zsh-scripts, java-programs, elf-binaries, ...
  3. are no dependencies of the aruba library itself

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.

Cezary Baginski
@e2
Docker is also a convenient way of testing things when dependencies are missing.
Matt Wynne
@mattwynne
I think @tooky's suggestion to skip the scenario if the environment is missing a dependency required for that scenario will work well for you.
Dennis Günnewig
@dg-ratiodata

@all Is there anybody interested in taking over maintainership of jarib/childprocess#104? It's a ruby library to run commands on MRI Ruby, JRuby, Linux, Windows, ... We use it in aruba.

Unfortunately I don't have much spare time nowadays. I want to spent the bit of my spare time on aruba. So any help is welcome.

Dan Black
@dyspop
:wave: hi there... sorry i'm a bit of a Ruby newb especially with BDD. Having a ton of trouble getting aruba to... do ... anything.
I'm working on a CLI gem to parse text files essentially. this room looks a bit... dead?
well... if anyone sees this :wave:
Knut P
@knutpett
👋
greybox99
@greybox99
hi
is it possible to test for multiple words
in the output of the bash command?
greybox99
@greybox99
anyone?
Eric Kessler
@enkessler
Is there a way to make the output comparison steps be line ending agnostic?
I need Aruba tests to work on Unix/Windows/OSX but they break because every platform has different line endings.
Jaysinh Shukla
@ultimatecoder
Hi, I am trying to write a functional test for this command line program. Please find my feature file here.
I want to describe the input. As you can see the commented part of "And I type" command.
Is there any way to describe more about the input?
Is comments the only option?
Brian Colfer
@bcolferzd
I’m running MacOS Mojave 10.14.5. I can gem install aruba with no errors but when I try aruba init I get:
/Users/me/.rbenv/versions/2.6.3/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': dlopen(/Users/me/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/ffi-1.9.17/lib/ffi_c.bundle, 9): Symbol not found: _ffi_type_double (LoadError)
Referenced from: /Users/me/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/ffi-1.9.17/lib/ffi_c.bundle
Expected in: flat namespace
in /Users/me/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/ffi-1.9.17/lib/ffi_c.bundle - /Users/me/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/ffi-1.9.17/lib/ffi_c.bundle