Failed to exec 'vagrant up' (rbenv, ruby 2.7.6, bundler 2.3.19, virtualbox) about beaker HOT 11 CLOSED

Maybe its about documentation discoverability? When I tried to get beaker running I looked here first:

No argument here.

Yes. It seems like it documents the basic structure. But maybe links to the reference documentation of those functions would be nice. I see that acceptance spec helper in puppet-motd uses configure_beaker in more advanced ways...

Correct, but I documented that on https://github.com/voxpupuli/voxpupuli-acceptance/#installing-puppet-modules.

from beaker.

I also tried it without rbenv and use ruby and bundler directly from the Debian 11 repos and it failed similarly.

from beaker.

I think it rings a bell: I do have this hack in ~/bin/vagrant (before anything else in my $PATH) so that vagrant when run from a Ruby bundle ignore this Ruby bundle completely:

#!/bin/sh

# Remove all bundler / rbenv environment variables
unset \
  BUNDLE_BIN_PATH \
  BUNDLE_GEMFILE \
  BUNDLE_ORIG_PATH \
  GEM_HOME \
  GEM_PATH \
  RBENV_DIR \
  RBENV_HOOK_PATH \
  RBENV_ROOT \
  RBENV_VERSION \
  RUBYLIB \
  RUBYOPT

# Adjust $PATH to remove rbenv additions
PATH=$(echo ":$PATH:" | sed -re 's,:/tmp/[^:]+/bin:,:,g' -e "s,:${HOME}/bin:,:,g" -e 's,/var/[^/:]+/.rbenv/shims:,,g' -e 's,^:(.*):$,\1,')

echo "===> /usr/local/bin/vagrant $@" >> /tmp/vagrant.log
pwd >> /tmp/vagrant.log
env >> /tmp/vagrant.log

# Run actual vagrant
exec /usr/local/bin/vagrant "$@"

I am on FreeBSD and am not sure this is required on systems where Vagrant provide packages, but I recall vaguely using this on Debian too… You may need to adjust a few things, at least the path to "real" vagrant on the last line. Does it help?

from beaker.

I found out that calling rake beaker... directly, without the bundler exec rake ..., seems to work.

So I guess that means that rake and the reset of the dependencies need to be installed into the ruby environment and cannot just stay in the project environment via bundle config set --local path vendor/bundle.

I also tested with vagrant-wrapper but, with that the process just gets stuck.

from beaker.

@smortex does have the right suggestion: you need to either install vagrant inside Bundler, or call vagrant in a way that cleans the environment from bundler.

I have installed vagrant via the Fedora repositories and that has a wrapper that cleans it up.

Having said that, the docs need a serious update. Ubuntu 14.04 is ancient and even if it starts up, I'm not sure how usable it is now.

Taking a step back, I'd recommend voxpupuli-acceptance since it deals with a lot of the complexities involved. I haven't looked into how well it works in a PDK environment, but I wouldn't expect problems.

from beaker.

@ekohl: Well AFAIK installing vagrant inside bundler is no longer supported. At least the latest gem 1.5.0 will complain about it. It also wasn't updated since 2014.

The documentation is somewhat spotty, with stuff like: Then you can call beaker-puppet methods, exactly as you did before.. Which also doesn't really help if you don't know how it was done before...

I am new to puppet, pdk, rspec, bundler and even ruby, so it could be very well be user error. I am currently just searching for way of least resistance of implementing and maintaining acceptance tests. I noticed that the PDK/puppet officially now supports litmus, but even with that I have issues and vagrant doesn't seems to work as advertised as well (it seems to just get stuck somewhere)...

Sorry for the rant... Maybe just take it as feedback from a newbie.

from beaker.

The complaints about Beaker documentation are fully justified. It hasn't really been updated in a long time. My goal with voxpupuli-acceptance was to make it easier to consume. Similarly, we have voxpupuli-test for our unit testing. Within Vox Pupuli we don't use PDK but rather things directly.

A quick overview:

• Puppet uses Ruby a lot
• RSpec is a common Ruby testing framework
• For unit testing rspec-puppet provides integration with RSpec
• Beaker is a framework to test on machines (virtual, containers)
• beaker-rspec provides integration with RSpec
• beaker and beaker-rspec use serverspec to make testing easier

PDK aims to bundle this to make it easier to consume, but IMHO it doesn't. At least when you're an advanced user, it mostly gets in the way. That's why for Vox Pupuli I wrote voxpupuli-test and voxpupuli-acceptance. In https://github.com/voxpupuli/modulesync_config we maintain the templates for our modules.

The biggest difference is that PDK has a lot of boiler plate it templates while in Vox Pupuli I aimed to extract that boiler plate to libraries and have minimal files instead.

from beaker.

@ekohl: Thanks for the reply and for the overview. I will keep the points about PDK in mind. I already found the limits of this template, for instance deactivating honeycomb just doesn't work there.

But I was more successful with litmus for now... well at least the acceptance tests now run on github-actions, but running it locally is currently broken as well there.

With beaker at least I could install it outside of binder to get the vagrant provisioner to work, but then it failed because puppet_module_install wasn't found and it wasn't clear to me how to access the host facts in the testcases. Litmus and the PDK had clearly documented that. Maybe some linking to some example or boilerplate integrations from the documentation would be helpful?

However it seems the vagrant situation seems even worse with litmus compared to beaker, I couldn't find a way to use vagrant with it.

from beaker.

Maybe some linking to some example or boilerplate integrations from the documentation would be helpful?

Is https://github.com/voxpupuli/voxpupuli-acceptance#usage not sufficient? Would a basic spec test help?

theforeman/puppet-motd#13 is an example using modern spec testing syntax. In most modules you'll find an older style, so that may be a bit confusing.

Of course, that is made easier by already having the boiler plate in place (Gemfile, Rakefile and spec_helper_acceptance.rb), but voxpupuli-acceptance documents those bits.

from beaker.

Maybe some linking to some example or boilerplate integrations from the documentation would be helpful?

Is https://github.com/voxpupuli/voxpupuli-acceptance#usage not sufficient? Would a basic spec test help?

Maybe its about documentation discoverability? When I tried to get beaker running I looked here first:

https://github.com/voxpupuli/beaker/tree/master/docs/tutorials

and especially the quick start:

https://github.com/voxpupuli/beaker/blob/master/docs/tutorials/quick_start_rake_tasks.md

Which I assumed would be a hand holding step by step guide on getting beaker up and running. (It wasn't really...)

Compared to litmus, where I first get linked to a github wiki, which then links to:

https://puppetlabs.github.io/litmus/

That pages is a bit annoying to navigate, because there is no really page index on the side, but it contained a clear guide how to integrate litmus into my own project:

https://puppetlabs.github.io/litmus/Converting-modules-to-use-Litmus.html

And also mentions puppetlabs-motd as an example of a litmus integrated module and how to run tests there:

https://puppetlabs.github.io/litmus/Running-acceptance-tests.html

And finally it described how to write basic tests and how to access puppet facts:

https://puppetlabs.github.io/litmus/Litmus-test-examples.html

with a link to serverspec.

Meanwhile I tried to learn how to read rubydoc documentation to figure out how to access facts in beaker and wonder where I get the current host from:

https://www.rubydoc.info/gems/beaker-puppet/Beaker/DSL/Helpers/FacterHelpers

theforeman/puppet-motd#13 is an example using modern spec testing syntax. In most modules you'll find an older style, so that may be a bit confusing.

That looks helpful.

Of course, that is made easier by already having the boiler plate in place (Gemfile, Rakefile and spec_helper_acceptance.rb), but voxpupuli-acceptance documents those bits.

Yes. It seems like it documents the basic structure. But maybe links to the reference documentation of those functions would be nice. I see that acceptance spec helper in puppet-motd uses configure_beaker in more advanced ways...

from beaker.

I think this is resolved in voxpupuli/beaker-vagrant#73.

from beaker.