not sure, if I look at the current solution it just uses a static setfile and lets beaker start the service container too

but that means we can't use the generated matrix based on metadata.json for acceptance tests

which may or may not be a problem for you - vault_lookup is just native Ruby code so it didn't matter too much

First step, get anything working. Then I can consider tidying it up if I get time. I'd prefer to spend the time on writing actual tests though.

Meanwhile... calling on ewoud's WaaS, any thoughts on https://github.com/voxpupuli/puppet-ldapquery/pull/47#discussion_r1205759961?

has beaker-module_install_helper been removed as a dependency from something??

Looks like it should now be a dependency of

beaker_puppet_helpers

???

we don't use beaker-module_install_helper anymore

What about https://github.com/voxpupuli/puppet-gitlab_ci_runner/blob/master/spec/spec_helper_acceptance.rb#L9?

Could you create a PR to fix?

that's dead and needs to be replaced

but what with?

install_puppet_module_via_pmt_on(host, 'puppetlabs-docker')

See the

puppetlabs-docker

module at https://forge.puppet.com/puppetlabs/docker?src=slack&channel=voxpupuli

https://github.com/voxpupuli/puppet-nginx/commit/cae3388db238b09374fabfe3d49d1fdf42882120 like here

I didn't understand "Installation of modules now happens by creating a module release (using puppet-modulebuilder) and running puppet module install on that. This is a lot faster than the old method because it happens in a single transaction." from https://github.com/voxpupuli/voxpupuli-acceptance/pull/54/commits/3af25a7dbc6ad2311e349f409f602d49433bacd6

Cool, I'll give that a go (in the ldapquery stuff I'm trying to get working)

and a PR to the README of the old gem would probably help.

@Alex Fisher https://github.com/voxpupuli/beaker-module_install_helper/pull/47 is that fine or do you want more docs?

we can also rework the readme of beaker_puppet_helpers if you like

afisher: perhaps we could have done a better job of adding a Migrating section to beaker_puppet_helpers

afisher: but the general summary of the modulebuilder bit is that we basically build a release of the module, which results in a tarball that would also download from forge.puppet.com

afisher: and the great thing is that puppet module install /path/to/local/module.tar.gz works and installs all dependencies according to metadata.json

I mentioned this a few days ago, but it got kinda lost in the shuffle:

So, I've got a slightly weird situation that I'm not sure is 100% covered in the "Migrating a module to Vox Pupuli" documentation: I've got a module that I'm interested in donating to Vox Pupuli (if you're interested in having it), but, I can no longer maintain it myself as we're no longer using the software managed with it (indeed that's the reason I want to transfer it). I do know that there are other users who are interested in the module, since I've received pull requests (which I've been unable to effectively review), though I can't speak for them as to whether they'd be interested in maintaining the module.

So, the module I want to migrate is _sort of "_abandoned", but, it was abandoned by me, and I'm not sure if I need to find someone else who wants to work with Vox Pupuli on it first, and transfer it to them, or what?

For reference, the module in question is philomory-graylog_api.

and that's MUCH faster than for each module that's a dependency call puppet module install

but obviously it's not going to know about soft dependencies in metadata.json, so there's still a need for manual module installation

This message was deleted.

I'm 100% happy if an author transfers their module and we maintain it within our infrastructure

there are benefits, like modulesync where we have more people taking care of the tooling so the author can focus more on the actual manifests

and more CI power!