You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current support for the Guard is severely limited by statically symlinking spec/fixtures/modules/<my-module> to the project root. See here for a more detailed discussion on the problem.
For example, I would like to speed up the whole rspec-puppet workflow by using something like the following in my Guardfile:
guard :rspec, cmd: 'rspec', cmd_additional_args: '--fail-fast' do
watch %r{^spec/classes/.*_spec\.rb$}
watch %r{^manifests\/(.*)\.pp$} do |m|
spec = "spec/classes/#{m[1]}_spec.rb"
spec if File.exists? spec
end
end
This simple example would call, e.g., rspec --fail-fast spec/classes/install_spec.rb whenever either manifests/install.pp or spec/classes/install_spec.rb changes on disk, which is kind of cool. However the problem is that guard will fail with complaining about the inifinite symlink look created by the symlink I mentioned above.
A possible approach would be to remove the symlinks stanza from .fixtures.yml and instead create these links only during the actual rspec run, for example with something like the following in spec/spec_helper.rb:
RSpec.configure do |config|
config.before :suite do
File.symlink('../../..', 'spec/fixtures/modules/<my-module>')
end
config.after :suite do
File.delete('spec/fixtures/modules/<my-module>')
end
end
Update: In fact, we would have to ensure there are no symlink loops in the whole project directory. Unfortunately, there are ill modules on GitHub containing such symlinks, for example puppetlabs/puppetlabs-stdlib. Thus if such ill modules are listed in .fixtures.yml we would get even more symlink loops somewhere below spec/fixtures/modules/<ill-module> after running rake spec_prep. These symlinks should probably removed upstream in the puppetlabs_spec_helper gem, where the spec_prep rake task is defined.
The text was updated successfully, but these errors were encountered:
The current support for the Guard is severely limited by statically symlinking
spec/fixtures/modules/<my-module>
to the project root. See here for a more detailed discussion on the problem.For example, I would like to speed up the whole
rspec-puppet
workflow by using something like the following in myGuardfile
:This simple example would call, e.g.,
rspec --fail-fast spec/classes/install_spec.rb
whenever eithermanifests/install.pp
orspec/classes/install_spec.rb
changes on disk, which is kind of cool. However the problem is thatguard
will fail with complaining about the inifinite symlink look created by the symlink I mentioned above.A possible approach would be to remove the
symlinks
stanza from.fixtures.yml
and instead create these links only during the actualrspec
run, for example with something like the following inspec/spec_helper.rb
:Update: In fact, we would have to ensure there are no symlink loops in the whole project directory. Unfortunately, there are ill modules on GitHub containing such symlinks, for example puppetlabs/puppetlabs-stdlib. Thus if such ill modules are listed in
.fixtures.yml
we would get even more symlink loops somewhere belowspec/fixtures/modules/<ill-module>
after runningrake spec_prep
. These symlinks should probably removed upstream in the puppetlabs_spec_helper gem, where thespec_prep
rake task is defined.The text was updated successfully, but these errors were encountered: