Puppet Community

Has anyone seen this particular failure before?

it looks like there is a newer version installed?

I take that back. A few on my mods have failed for EL8 and EL9

it could be worse, I'm trying to debug cgi

<@U020LK7D0JU> the base docker image is amd64/almalinux:8: <https://github.com/lsst-it/puppet-smee/actions/runs/5348548057/jobs/9698569957?pr=13>

you're also installing the el7 package on el8?

its the same docker image in all my repos

it is only failing in some and it is repeatable for those the fail

I'm not sure where amd64/almalinux:8 is coming from

for centos7 you try to install the package multiple times

The change here is gem 'voxpupuli-acceptance', '~&gt; 2.0', :require =&gt; false

huh, `<http://docker.io/amd64/almalinux:8|docker.io/amd64/almalinux:8>` is a thing. I didn't know that.

with voxpupuli-acceptance we moved to a new docker major release

I've got `clone_git_repo_on` breakage too which I completely don't understand:
```An error occurred in a `before(:suite)` hook.
Failure/Error:
  clone_git_repo_on(host, '/etc/puppetlabs/code/environments/production/modules',
                    name: 'scl',
                    path: '<https://github.com/lsst-it/puppet-scl>',
                    rev: 'production')
NoMethodError:
  undefined method `clone_git_repo_on' for main:Object
  
    clone_git_repo_on(host, '/etc/puppetlabs/code/environments/production/modules',
    ^^^^^^^^^^^^^^^^^```
It appears to still be in beaker-puppet: <https://github.com/voxpupuli/beaker-puppet/blob/master/lib/beaker-puppet/install_utils/foss_utils.rb#L188>

I guess I need to ask the stupid question of, how do I install a puppet module from source in an acceptance test?

bastelfreak: thanks for reviewing and merging that webhook-go PR

this is testing with a module dep that is not released on the forge, the git needs to be installed via git

use the fixtures method documented in the readme

although, this isn't great in the sense that the dep is only for the acceptance test, regular spec doesn't need it

the good news is that fixes acceptance tests. The bad news is blows up rspec-puppet because it seems it doesn't like the ref being a branch name???

```fatal: ambiguous argument 'production': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git &lt;command&gt; [&lt;revision&gt;...] -- [&lt;file&gt;...]'```

<https://github.com/lsst-it/puppet-smee/pull/13/files>

i'm nuking the .bundle dir and reinstalling clean

<https://github.com/puppetlabs/puppetlabs_spec_helper#using-fixtures|https://github.com/puppetlabs/puppetlabs_spec_helper#using-fixtures>

I had tried that and gotten the same failure

but now its working after nuking .bundle and reinstalling

ok, I think the other problem is that `configure_beaker` is in `spec_helper_acceptance.rb` but I've also got `configure_beaker(modules: :fixtures)` under `spec/support` . I guess I'll have to unmanage `spec_helper_acceptance.rb` for the moment. Should we add some templating into `spec_helper_acceptance.rb.erb`?

I understand. It just means having to unmanage spec_helper_acceptance.rb even in trivial cases

so removing the plain `configure_breaker` actually breaks it completely because the a copy of the module being tested isn't installed at all

did you run the spec_prep task so the stuff is published locally?

is this like the old days and "self" needs to be in fixtures?

fails under gha: <https://github.com/lsst-it/puppet-smee/actions/runs/5349146427>

check the readme again, you need to call spec_preo before running beaker :)

ok... but this is     uses: voxpupuli/gha-puppet/.github/workflows/beaker.yml@v1

I don't see an input to <https://github.com/voxpupuli/gha-puppet/blob/v1/.github/workflows/beaker.yml> to add extra rake targets

we added support for fixtures brcause other might use it. the foreman people for example

right... so they are changing their `beaker` task then?

but it isnt templated in our modulesync_condig bevause vox pupuli doesnt use it

`task :beaker =&gt; "spec_prep"` is all you need I think

that should run the spec_prep task every time beaker is called

so I should probably publish the stupid fork to the forge

which is why I haven't done anything as EL7 is on its last days

Argh <https://github.com/lsst-it/puppet-smee/actions/runs/5349265766/jobs/9700248466>

because of course the gems aren't installed

yes. add puppetlabs_spec_helper to the system_tests group

argh, and I need to unmanage Rakefile as well

I figured out I can just use `./rakelib/beaker.rb` and not have unmanage `Rakefile`

more ugh. .fixtures.yml doesn't do dep resolution... so I need to work out recursive deps to convert to fixtures...

why again don't you use the normal installation method? :smile:

when they were installed the old way with pmt it pulled down deps

1:1 conversion to .fixtures.yml fails because no dep resolution... just another gotcha

it would be way better if we put in a `Puppetfile` and use librarian for fixture setup as it would resolve deps

yeah but why do you need to use the fixtures inszallation method at all?

because I use puppet modules for setting up the acceptance test that aren't deps of the module itself

because I don't want to add a dep to puppet/yum, epel, etc. to all my modules because that makes re-composition hard

See the `puppet-yum` module at <https://forge.puppet.com/puppet/yum?src=slack&amp;channel=voxpupuli>

there are also methods to install deps for acceptance tests

you mean #install_module_from_forge_on, which I was using?

wait, are we keeping <https://github.com/voxpupuli/beaker-module_install_helper|beaker-module_install_helper>?

right... so what option is there other than `.fixtures.yml`?

like we did it in the past, read the deps from metadata.json. and if you have deps specific for acceptance tests you can install them like <https://github.com/voxpupuli/puppet-grafana/blob/master/spec/spec_helper_acceptance.rb#L11|https://github.com/voxpupuli/puppet-grafana/blob/master/spec/spec_helper_acceptance.rb#L11>

```install_puppet_module_via_pmt_on```
is the replacement for
```install_module_from_forge_on```

how about aliasing it to install_module_from_forge_on?

that would have saved me some grief today

I am not sure if the params are identical

but I considered a wrapper, that would be nice

copy. I don't know how I missed the discussion on this revamp. I would have been more than willing to help.

<https://github.com/voxpupuli/beaker_puppet_helpers/blob/master/lib/beaker_puppet_helpers/module_utils.rb|https://github.com/voxpupuli/beaker_puppet_helpers/blob/master/lib/beaker_puppet_helpers/module_utils.rb>

backtracking a bit, should I merge <https://github.com/voxpupuli/modulesync_config/pull/837> or do you want to think about it more?

I honestly never use pmt so I'm unsure how it deals with version constraints

I think thats already a good enough improvement so that we can merge it

pmt honours major version constraints and poops itself if you try to violate them

it forces us to review module dependencies, which I like. with stuff like stdlib 9 we see that version constraints actually make sense

I know that it won't downgrade already installed modules, which is sort of  pita. I see that in acceptance tests if stdlib 9 gets installed and then its invoked again for a mod that only wants stdlib 8

it would be really great to just use a Puppetfile and librarian

```  error during compilation: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, deprecation. ensure_packages. This function is deprecated, please use stdlib::ensure_packages instead. at ["/home/runner/work/puppet-ccs_software/puppet-ccs_software/spec/fixtures/modules/sudo/manifests/package.pp", 76]:["/home/runner/work/puppet-ccs_software/puppet-ccs_software/spec/fixtures/modules/sudo/manifests/conf.pp", 50] (file: /home/runner/work/puppet-ccs_software/puppet-ccs_software/spec/fixtures/modules/sudo/manifests/package.pp, line: 76, column: 9) (file: /home/runner/work/puppet-ccs_software/puppet-ccs_software/spec/fixtures/modules/ccs_software/manifests/service.pp, line: 56) on node <http://fv-az612-160.gqp4uj4dnjkevoqu2sjlt0n5ta.cx.internal.cloudapp.net|fv-az612-160.gqp4uj4dnjkevoqu2sjlt0n5ta.cx.internal.cloudapp.net>```

see, thats why we use pmt and metadata.json :D

it is only failing on puppet 8 though... puppet 7 passes

and the readme has some more details <https://github.com/voxpupuli/voxpupuli-acceptance|https://github.com/voxpupuli/voxpupuli-acceptance>

dhollinger: i hope the PR was good enough

```install_puppet_module_via_pmt_on```
doesn't work with version constraints... it seem that pmt only works with fixed version strings???