Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing spec_helper_acceptance.rb ? #177

Closed
madAndroid opened this issue Jun 6, 2016 · 6 comments
Closed

Missing spec_helper_acceptance.rb ? #177

madAndroid opened this issue Jun 6, 2016 · 6 comments

Comments

@madAndroid
Copy link

On a fresh clone of this repo, following the instructions in the README.md, and attempting a sync, a get the following error:

~/r/v/modulesync_config git:master  ❯❯❯❯ bundle exec msync update -f jenkins --message "modulesync 0.7.0"
Syncing puppet-jenkins_job_builder
Overriding any local changes to repositories in ./modules
Switching to branch modulesync
bundler: failed to load command: msync (/srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/bin/msync)
Errno::ENOENT: No such file or directory @ rb_sysopen - ./moduleroot//spec/spec_helper_acceptance.rb
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/gems/modulesync-0.6.1/lib/modulesync/renderer.rb:14:in `read'
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/gems/modulesync-0.6.1/lib/modulesync/renderer.rb:14:in `build'
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/gems/modulesync-0.6.1/lib/modulesync.rb:77:in `block (2 levels) in run'
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/gems/modulesync-0.6.1/lib/modulesync.rb:68:in `each'
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/gems/modulesync-0.6.1/lib/modulesync.rb:68:in `block in run'
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/gems/modulesync-0.6.1/lib/modulesync.rb:57:in `each'
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/gems/modulesync-0.6.1/lib/modulesync.rb:57:in `run'
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/gems/modulesync-0.6.1/bin/msync:8:in `<top (required)>'
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/bin/msync:23:in `load'
  /srv/data/repos/voxpupuli/modulesync_config/.vendor/ruby/2.1.0/bin/msync:23:in `<top (required)>'

It does appear that spec_helper_acceptance.rb is indeed missing; even when I pull that in from the puppet module skeleton, the run appears to still fail - is there something else that I'm missing?

@jyaworski
Copy link
Member

@madAndroid you're correct. In the .sync.yml is there an entry for that file? That's why it's failing I'd imagine. We really should ship that file though, @bastelfreak.

@bastelfreak
Copy link
Member

I don't know when that got removed from modulesync. I barely work with acceptance tests, but I think the file looks very different on multiple modules. As a short term solution just delete the line from the .sync.yml

@madAndroid
Copy link
Author

Yes indeed, I've added unmanaged: true for that file in .sync.yaml for now - that appears to have sorted it out.

I've worked quite a bit with Beaker over the past year or so, perhaps we should look at including the spec_helper_acceptance.rb from garethr's puppet_module_skeleton repo? it appears to be one that a lot of people are using.

@bbriggs
Copy link
Contributor

bbriggs commented Jun 27, 2016

I can send a preliminary PR for this.

@vinzent
Copy link
Contributor

vinzent commented Dec 31, 2016

in puppet-selinux i've added some shared_examples to the spec_acceptance_helper and added handling of selinux enabling: https://github.com/voxpupuli/puppet-selinux/blob/master/spec/spec_helper_acceptance.rb

where should module specific before(:suite) and maybe also after(:suite) be managed? require_relativ a module specific helper like spec_helper_acceptance_module.rb if it exists?. I don't know if it works to simply place another RSpec.configure block.

@ekohl
Copy link
Member

ekohl commented Nov 6, 2020

There now is one, but it's unmanaged by default. Given that, I'm closing this now.

@ekohl ekohl closed this as completed Nov 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants