If there is no way around it, i will survive with EPEL, but i’d rather not have it.

This message was deleted.

so first we should deploy voxpupuli-rubocop to all gems we have, cleanup rubocop violations, release them, update rubocop in voxpupuli-test, roll that out, update metadata.json to drop puppet 6, add puppet 8, during that maybe drop EoL operating systems because we need to do a major release anyway, then do the releases

(a shitload of work)

I collected issues in this project: https://github.com/orgs/voxpupuli/projects/4 . some of the PRs are ready for review

@bastelfreak so far i was able to avoid using epel. So does it mean it’s a no? 🙂

I don't know out of my head

where is that even using epel

I would vote for dropping puppet6 and doing major version bumps right away instead of holding off until puppet8 support is landed. I'm concerned that waiting for puppet 8 would meean keeping ruby 2.5 going as part of CI for a very long time.

oh is epel a dep from the python dep maybe

I would vote for dropping puppet6 and doing major version bumps right away instead of holding off until puppet8 support is landed. I'm concerned that waiting for puppet 8 would mean keeping ruby 2.5 going as part of CI for a very long time.

I don't know if that's configureable

yes I tried adding

class { 'python':

use_epel => false,

yes I tried adding

class { 'python':

use_epel => false,

hard coded inclusion of epel should be considered an antipattern. All mods should have a param to disable that.

hard coded inclusion of epel should be considered an antipattern. All mods should have a param to disable that.

That didn’t help.

@Brian Schonecker has left the channel

@bastelfreak I'm working on a forge module that has what appears to be a very hacked-in PDK support (based on all the pinned gems in .sync.yml). It is using puppetlabs_spec_helper 3.0 which has a set of beaker rake tasks included. So if I update to current pdk, I loose that somewhere between 3.0 and 5.0. I'm trying to touch this module lightly to improve the chances of a speedy merge. I've considered the voxpupuli-acceptance gem, but I'm just curious how likely this is to start breaking unforeseen things? Suggestions? THe lightest touch is likely the best.

depends on what you aim for. if you want a ptoper CI matrix, and want to use modern ruby, you probably need to update a lot

then you can just switch to our voxpupuli-acceptance

This message was deleted.

Hi Vox 👋 I'd like to release a new version of

puppet-vault_lookup

. I've prepared a release PR for review here: • https://github.com/voxpupuli/puppet-vault_lookup/pull/74

See the

puppet-vault_lookup

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

Puppet Content and Tooling Releases Tooling We have chosen to continue to build on PDK as the future direction of Puppets developer tooling and to archive Puppet Content Templates (PCT) and Puppet Runtime Manager (PRM). These projects provided valuable lessons which will be fed into PDK 3.x The full details of this approach can be found discussed in the blog https://www.puppet.com/blog/faq-puppet-developer-kit-pdk If any part of the community wants to adopt these projects for their own use please let us know. • Puppet Content Templates (PCT) - Archived and moved to https://github.com/puppetlabs-toy-chest/pct • Puppet Runtime Manager (PRM) Archived and moved to https://github.com/puppetlabs-toy-chest/prm Posted in #puppet

can or does beaker somehow use the default_facts.yml or default_module_facts.yml? or are these only for unit testing?

only for unit testing

check https://github.com/voxpupuli/voxpupuli-acceptance#customizing-host-configuration to manipulate the beaker instances

okay, i did something like that, but thought maybe i can use what i already have from my unit tests 🤷 😄

I guess you could enhance voxpupuli-acceptance to also read those facts, but now it only reads env vars: https://github.com/voxpupuli/voxpupuli-acceptance#environment-variables-to-facts