Puppet Community

may i get an review pls? :smile:
<https://github.com/voxpupuli/beaker-docker/pull/84>

<@U11MKJ5D4> as you’re on it anyway… may I ask you to try to remove those lines and test it in your environment?
<https://github.com/voxpupuli/beaker-docker/blob/master/lib/beaker/hypervisor/docker.rb#L80-L82>

The idea why is here: <https://github.com/voxpupuli/beaker-docker/issues/70>

In short words I believe container runtime should be able to bind the port w/o explicit port mapping

sry, i want to keep my pr to one topic only. so i can focus on testing one thing i do not completely understand :smile:

np, just if you got a chance :slightly_smiling_face:

my local setup is a bit limited right now.. so I was able to check just with podman

AFAIK this is discussed right now, with Puppet 8 being delayed. There was a thread a few days back.

I missed the memo on puppet8 being pushed back. there hasn't been any traffic on puppet-dev for months.

<@U11567REE> Has a time of death been called for puppet6?

<@U1QVBAUS2> yes yesterday was the last day for puppet6. I('ll ping some folks about getting an announcement out. As for Puppet 8, we have nightly puppet-agent packages available on <https://nightlies.puppet.com> No exact date yet, but we're working on it!

at the core office hours they said the p6 EOL date is not changed

there seemed to be some resistance on the mailing list to dropping puppet6 from the metadata.json in voxpupuli mods until it was officially dead.

I would like to first update our tooling to work on ruby 2.7-3.2, when that is done we have a reason to drop puppet 6

I'm surprised anything still works on 2.5.

Do you have a wishlist of things to update?

and I would like to have one rubocop config im bewker that all beaker plugins use and ideally the same for puppet-lint

what I did in the past weeks: introduce rubocop, fix violations, see if we can drop ruby 2.4/2.5/2.6, bump rubocop

I am collecting issues here: <https://github.com/orgs/voxpupuli/projects/4|https://github.com/orgs/voxpupuli/projects/4>

re: rubocop -- I have proposed updating modulesync_config to pin the .rubocop.yml to a specific branch/tag so that we can make further changes

Is a release and a modulesync in the same PR a well accepted practice?

I don't inherently object to it but I'm not sure if I've seen that before.

Was doing the release and recalled we merged tooling that help with it so I gave it a try. We do not usually do this.

Since these changes do not affect end-users, I am not too reluctant to integrate them in another PR if it makes our life easier. I think I already did it one or two times with failing release PR that needed an update.

But I can open another PR that only include the first commit and tag it as "modulsync" if people think it's better to "split" :slightly_smiling_face: Just tell me!

I'm am OK with module + release in the same PR as it reduces the tedium .

but as it is a changing of what I suspect most would consider a 'norm' it might be a good idea to go a few more people on board with it

Yay, I'll open a distinct PR and reference it

I commented on the PR that I'm in favor of the practice

:+1: I opened <https://github.com/voxpupuli/puppet-postfix/pull/348> anyway because we can have it for free and it match what we are used to do. Maybe some people will bring some more insights.

Also this old one: <https://github.com/voxpupuli/puppet-openldap/pull/369>

the rubocop conf can "inherit" from a url instead of a gem so we could pin the config explicitly. E.g. <https://docs.rubocop.org/rubocop/configuration.html#inheriting-configuration-from-a-remote-url>

I dont have an opinion on that at the moment, but I am also quite tired and its late :D

we can talk about it next week when we are both tired :wink: