Github action "basic.yml" fails because Gem parallel_spec is not sepcified/installed.

[bschonec]

I'm trying to use the gha-puppet reusable workflows for the first time and the parallel_tests are failing. I can only assume this is because the parallel_spec Gem is not installed.

I'm very green at this so I don't know where the solutions is. The output error when I have a completely generic project is:

Run ruby/setup-ruby@v1
Modifying PATH
Downloading Ruby
Extracting  Ruby
Print Ruby version
Installing Bundler
> bundle install
/opt/hostedtoolcache/Ruby/3.0.5/x64/bin/bundle config --local path /home/runner/work/junk/junk/vendor/bundle
/opt/hostedtoolcache/Ruby/3.0.5/x64/bin/bundle lock
Fetching gem metadata from https://rubygems.org/.......
Could not find gem 'parallel_spec_standalone' in rubygems repository
https://rubygems.org/ or installed locally.
Error: The process '/opt/hostedtoolcache/Ruby/3.0.5/x64/bin/bundle' failed with exit code 7

I added "gem 'parallel_tests'" to my Gemfile and it seemed to make things better.

[bastelfreak]

a minimal Gemfile I extracted from one of our modules:

source ENV['GEM_SOURCE'] || 'https://rubygems.org'

group :test do
  gem 'voxpupuli-test', '~> 5.5',   :require => false
  gem 'coveralls',                  :require => false
  gem 'simplecov-console',          :require => false
  gem 'puppet_metadata', '~> 2.0',  :require => false
end

group :system_tests do
  gem 'voxpupuli-acceptance', '~> 1.0',  :require => false
end

gem 'rake', :require => false
gem 'facter', ENV['FACTER_GEM_VERSION'], :require => false, :groups => [:test]

puppetversion = ENV['PUPPET_GEM_VERSION'] || '>= 6.0'
gem 'puppet', puppetversion, :require => false, :groups => [:test]

can you give that a try? we probably need to update the README.md.

[bschonec]

I used only the code you recommended and the Github action succeeded.

[ekohl]

I think you uncovered something I didn't consider, since we always pull in parallel_tests: https://github.com/voxpupuli/voxpupuli-test/blob/394a217026214ae79e6944807a497e822e1e3c34/voxpupuli-test.gemspec#L22

puppetlabs_spec_helper doesn't have a task that says "run spec tests, use parallel_test if available". Thinking about it, I'd say we should recommend parallel_tests to be included here, rather than contributing a patch to `puppetlabs_spec_helper.

And perhaps we should also provide an example in README.md that is what we have in our modules. Right now it only has that in a comment as a user exercise, but a direct example is probably better.

[bschonec]

As a brand new user of this project, the other thing that I've found is that creating only the Gemfile and Rakefile is not enough to be successful. The metadata.json .github/workflows/puppet.yml (and other files) need to be created as well. Seasoned uses of this project will consider that obvious but from my point of view the README.md needs to be more noob friendly. I was able to run the Github workflows successfully only after running "pdk new module". That's probably more than the minimum required but it'd be nice if the README.md was updated with the minimum information needed to be successful.

[ekohl]

That is good feedback. I always struggle to put myself into the position of a beginner; those responses help me a lot.

[bschonec]

Can the README.md be updated with examples that work? The latest error I have in the most simple of puppet modules is:

Run bundle exec rake rubocop
cannot load such file -- rubocop-performance

[ekohl]

Can you share your module? I wonder if your RuboCop config requires a plugin that isn't in your Gemfile.

[bschonec]

I'm using the Gemfile suggested by @bastelfreak. It did work months ago but now it's giving me:

The project is located here and the commit I used is here.

[ekohl]

That's IMHO an unrelated issue. You have https://github.com/bschonec/cicd-lab/blob/f7187bd38fdb01e9a3ede50efd2a3a6f01c5d33c/.rubocop.yml#L3 but I don't see RuboCop in https://github.com/bschonec/cicd-lab/blob/puppet-tests/Gemfile.

[bschonec]

Yeah, that's my struggle. The Gemfile in the README.md isn't sufficient for a successful run.

Most certainly, I didn't create the .rubocop.yml file manually because (as evidenced) I have no idea what I'm doing. Perhaps it got created with 'pdk new module' or something.

[ekohl]

It's a tricky problem, because in your situation it also doesn't work locally. Perhaps we should point to https://github.com/voxpupuli/modulesync_config as a reference for the least minimal config (which is what the example in README actually tries to achieve).

[bschonec]

I think this would just shift the confusion [on my part] from one project to another. modulesync_config doesn't do a good job of explaining what it does or why one would want to use it.

[bastelfreak]

@bschonec I updated the README.md with an up2date Gemfile. Could you test that?

[bschonec]

I created an entirely new module with "pdk new module", modified the Gemfile and Rakefile per the README.md, created two Github workflow YML files per the README.md (with Rubocop disabled?) but the workflow still errors.

[bastelfreak]

In https://github.com/bschonec/cicd-lab/blob/master/.rubocop.yml#L3 you reference a rubocop plugin that you don't install. We don't use it at vox pupuli for our puppet modules. You can remove it from the rubocop config, or add the gem to your Gemfile or replace the whole rubocop config with the one we use at vox pupuli (this requires the voxpupuli-test gem, which you already have in the gemfile):

---
inherit_gem:
  voxpupuli-test: rubocop.yml

[bschonec]

PDK created that file. As a person who has zero experience setting this up, the process of creating a new module with "pdk new module" and then following the instructions in the gha-puppet/README.md don't give an amateur like me enough information to get a Github action up and running without knowing the prerequisite knowledge regarding the Rubocop stuff. Could the README be update with "If you've created your module with PDK, ensure that you remove (or add) XXXX YYYY from the .rubocop.yml/Gemfile" ???

[bastelfreak]

The problem here is, we don't know which files pdk creates. The files and their content change from time to time and we don't use pdk for our module so we don't have an overview about the current pdk state.

[ekohl]

I created an entirely new module with "pdk new module", modified the Gemfile and Rakefile per the README.md, created two Github workflow YML files per the README.md (with Rubocop disabled?) but the workflow still errors.

I usually ignore the PDK altogether. While it's rare that I create a new module, I usually use our modulesync config. voxpupuli/modulesync_config#853 documents that workflow.

PDK created that file. As a person who has zero experience setting this up, the process of creating a new module with "pdk new module" and then following the instructions in the gha-puppet/README.md don't give an amateur like me enough information to get a Github action up and running without knowing the prerequisite knowledge regarding the Rubocop stuff. Could the README be update with "If you've created your module with PDK, ensure that you remove (or add) XXXX YYYY from the .rubocop.yml/Gemfile" ???

I'll be honest and say that I don't have time to look into that now. PDK does so many things I strongly disagree with that I don't want to touch it and I'm already busy with $dayjob.

This year at cfgmgmtcamp I gave a presentation with how it's built, which does go through the various steps. If I had time, I'd rather expand that in a blog so you know how it's built from scratch.

I've opened #38 to further refine the Gemfile example part.

[bschonec]

@ekohl, your link to your presentation is 404 (invalid).

CORRECTION: Here's the correct URL:

[ekohl]

Oh yes, somehow GH's markdown parsing got confused on the spaces. Correct now.