Ask Your Question

Code compile checks?

asked 2016-12-01 10:48:20 -0600

evil_del gravatar image

We have a monolithic repo with multiple defined roles, e.g: webserver, dbserver

I would like to check that all the code in our production branch would compile OK for each role. Is there a way I can compile a catalog to test the code doesn't fail for role: webserver?

I realise I would have to supply facts. Ideally I could supply a file of facts from a recent agent run report?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2016-12-01 16:15:26 -0600

DarylW gravatar image

updated 2016-12-01 16:17:19 -0600

I am working on a similar setup myself. There are several ways you can approach this problem. One example was demoed at puppetconf this year from github... octocatalog-diff

Here is the project - - Here's the video

The tool has the ability to reference the facts from a specific node, and you can diff the catalog it creates against the catalog from the node, or from a different branch or.... lots of other places.

The approach that I am taking is to set up a test that loops through all of my roles, presets up facts, ties into our hiera data, and then calls it { should compile.withalldeps } for every role. I initially staged my question here

Some additional information... You can do facter -yto output your facter facts as yaml on a node. You also can load facts into RSpec either in your Rakefile or in your _spec.rb files. In the nginx module at they have a default_facts.yaml file, which you can see being read into their spec_helper.rb file

RSpec.configure do |c|
  default_facts = {
    puppetversion: Puppet.version,
    facterversion: Facter.version
  default_facts.merge!(YAML.load('../default_facts.yml', __FILE__)))) if File.exist?(File.expand_path('../default_facts.yml', __FILE__))
  default_facts.merge!(YAML.load('../default_module_facts.yml', __FILE__)))) if File.exist?(File.expand_path('../default_module_facts.yml', __FILE__))
  c.default_facts = default_facts
  c.mock_with :rspec

Hieradata is a different thing...

If you wish to use your hieradata, the way that I am currently doing it is as follows... in my spec tests where I wish to use the hieradata, I am setting the hiera_config value with let(:hiera_config){'spec/fixtures/hiera.yaml'}. If you wish to embed test hieradata, I have seen people create a spec/fixtures/hieradata/common.yaml and have a really simple hiera.yaml that points appropriately to the hierarchy there.

If you are putting these tests directly in your control repo (since most people have their roles, profiles, and hieradata there) you could just have a relative reference to your hieradata, similar to this.. It assumes your role fact is named my_role

# spec/fixtures/hiera.yaml
 - yaml
  - "role/%{::my_role}"
  -  common
  #insert the appropriate number of ../ to reach the appropriate directory
  :datadir: "../../../hieradata"
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2016-12-01 10:48:20 -0600

Seen: 68 times

Last updated: Dec 01 '16