Add support to rsync fixtures into SUTs#49
Add support to rsync fixtures into SUTs#49bastelfreak wants to merge 1 commit intovoxpupuli:masterfrom
Conversation
652ea2c to
025b15e
Compare
| # The directory where the modules sit | ||
| # @param [String] destination | ||
| # The directory where the modules will be placed | ||
| def install_puppet_modules_via_rsync(hosts, source = 'spec/fixtures/modules/', destination = '/etc/puppetlabs/code/environments/production/modules') |
There was a problem hiding this comment.
Normally we try to use settings. If you do, you probably can't use the rsync_to helper and your code looks more as it did in the previous version. Just make it destination = nil and if nil, read the value from Puppet's settings. I don't think we have a helper for that (anymore).
It probably comes down to using puppet config print environmentpath and puppet config print environment to determine the destination. That should also help with non-standard configurations.
I also wonder if there should be a default for source because I think making a mandatory parameter is better. That way users of the API are forced to think about it.
Another thought: in foreman-infra we use environment.conf to load multiple directories with modules. In my design I kept module vs repo testing separate. For voxpupuli-acceptance is the tooling intended to make individual module testing easy. This library should make testing Puppet easy. That sort of makes an argument for it to be in voxpupuli-acceptance.
There was a problem hiding this comment.
My idea was that this helper method isn't Vox Pupuli specific so I added it here and not in voxpupuli-acceptance. I applied the defaults that we/beaker sets during tests at the moment. Let me know if you prefer it in voxpupuli-acceptance and I can move it.
There was a problem hiding this comment.
My feeling now is that the implementation is so trivial. However, if you are smarter and read the destination from Puppet's config on the target machine then it certainly makes sense.
At this moment I'm a bit unsure what's best.
Co-authored-by: Ewoud Kohl van Wijngaarden <ewoud@kohlvanwijngaarden.nl>
No description provided.