Control repo validation

[patrickmayes]

Requesting to pdk to be able to validate Puppetfile, manifests/site.pp, and modules under the site folder for roles/profiles checking as well as hieradata yaml files.

[scotje]

Thanks @patrickmayes ! We've actually been scoping this feature recently and hope to be posting an RFC for it in the near future, which we'll make sure to link back here.

[genebean]

Can I get a status update on this?

[logicminds]

There is a new ra10ke validate function for validating Puppetfiles.

https://github.com/voxpupuli/ra10ke#r10kvalidatepath

[patrickmayes]

So if I'm understanding this correctly, I would need to setup rake with ra10ke to validate the puppetfile for rake, I would have to setup rspec to test the modules under site for roles and profiles and the site.pp. Then come up with a hiera data validator to test all my hiera data? Would be nice if PDK has all of this functionality in it so I could call a command to validate the control repo and it does it rather than setting up 3-4 different items and come up with the scripting myself.

[natemccurdy]

+1 to this as these same features would be useful in a monorepo setup where all your modules are under site-modules/ in the control repo (as is the case with some organizations I work with).

I think another way to look at this problem is to think of it as giving PDK a "global" config or common scaffolding to use for all subdirectories. If those subdirectories happen to be modules, PDK would use the global config unless overridden by some module-specific PDK configs.

Edit: Another example of why I am very much for this proposal. For those groups I work with that do have monorepo type of Control Repos, there are dozens of modules that we've converted to PDK and all of them have the exact same boilerplate in them. This is a massively inefficient way to do this. The same Gemfile, same Rakefile, same PDK template version, same dotfiles, etc... The only thing different per module is the tests in the spec/ directory, basically.

I'd very much like to see the ability to use a single set of PDK boilerplate for a control repo and have each module have its own tests. And this issue, to me anyway, kind of touches on those same points.

[genebean]

@glennsarti & @jpogran ^^

[glennsarti]

Hrmm

PDK boilerplate for a control repo and have each module have its own tests.
That seems like a tricky problem.

Also setting an rspec root (--default <path>) can have unintended consequences

Definitely multiplies the combinations of "where is a module?" e.g. Module detection would start to look like;

• Am I in the root of a module (has metadata.json)
• Am I in a child path of a module (has metadata.json)
• Am I in a module with no metadata.json (like roles and profiles)
• Am I in a control repo with a custom module path (environment.conf)
  etc. etc.

Do we finally need to have a .pdk.yml (or whatever filename) to keep pdk settings AND be used as a place to detect workspace roots?

That said ... My PDK Template V2 RFC may cover some of this e.g. opt-ing out Gemfile and other bits-and-bobs which you don't want

[natemccurdy]

@glennsarti @jpogran #980 has a better example of what I'd want the PDK to do.

Being able to descend into sub-dirs to find modules is a stretch, yes, but at least being able to run pdk commands from anywhere or against a specified directory would be great in a control-repo setting or for git hooks.

[genebean]

I would still very much like to see this happen.