Github action "basic.yml" fails because Gem parallel_spec is not sepcified/installed. about gha-puppet HOT 20 OPEN

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.

from gha-puppet.

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

from gha-puppet.

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.

from gha-puppet.

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.

from gha-puppet.

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

from gha-puppet.

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

from gha-puppet.

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

from gha-puppet.

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.

from gha-puppet.

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.

from gha-puppet.

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.

from gha-puppet.

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).

from gha-puppet.

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.

from gha-puppet.

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

from gha-puppet.

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.

from gha-puppet.

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

from gha-puppet.

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" ???

from gha-puppet.

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.

from gha-puppet.

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.

from gha-puppet.

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

CORRECTION: Here's the correct URL:

from gha-puppet.

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

from gha-puppet.